{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "perf-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-57.0.0.59.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-57.0.0.59.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-57.0.0.59.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "perf-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-57.0.0.59.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-57.0.0.59.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-57.0.0.59.oe2403"
            }
          ],
          "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:  bpf: support non-r10 register spill/fill to/from stack in precision tracking  Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset.  To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don\u0026apos;t touch idx field for maximum performance, as it\u0026apos;s checked most frequently during backtracking.  This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches.  There are only three differences in selftests\u0026apos; BPF object files according to veristat, all in the positive direction (less states).  File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF) --------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  ------------- test_cls_redirect_dynptr.bpf.linked3.o  cls_redirect        2987       2864  -123 (-4.12%)         240         231    -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o         syncookie_tc       82848      82661  -187 (-0.23%)        5107        5073   -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o         syncookie_xdp      85116      84964  -152 (-0.18%)        5162        5130   -32 (-0.62%)  Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees.  Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry\u0026apos;s insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don\u0026apos;t want to entries, so we need to reuse last added entry, if it is present.  Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that.    [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/(CVE-2023-52920)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only mark \u0026apos;subflow\u0026apos; endp as available\r\n\r\nAdding the following warning ...\r\n\r\n  WARN_ON_ONCE(msk-\u0026gt;pm.local_addr_used == 0)\r\n\r\n... before decrementing the local_addr_used counter helped to find a bug\nwhen running the \u0026quot;remove single address\u0026quot; subtest from the mptcp_join.sh\nselftests.\r\n\r\nRemoving a \u0026apos;signal\u0026apos; endpoint will trigger the removal of all subflows\nlinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with\nrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used\ncounter, which is wrong in this case because this counter is linked to\n\u0026apos;subflow\u0026apos; endpoints, and here it is a \u0026apos;signal\u0026apos; endpoint that is being\nremoved.\r\n\r\nNow, the counter is decremented, only if the ID is being used outside\nof mptcp_pm_nl_rm_addr_or_subflow(), only for \u0026apos;subflow\u0026apos; endpoints, and\nif the ID is not 0 -- local_addr_used is not taking into account these\nones. This marking of the ID as being available, and the decrement is\ndone no matter if a subflow using this ID is currently available,\nbecause the subflow could have been closed before.(CVE-2024-45010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvideo/aperture: optionally match the device in sysfb_disable()\r\n\r\nIn aperture_remove_conflicting_pci_devices(), we currently only\ncall sysfb_disable() on vga class devices.  This leads to the\nfollowing problem when the pimary device is not VGA compatible:\r\n\r\n1. A PCI device with a non-VGA class is the boot display\n2. That device is probed first and it is not a VGA device so\n   sysfb_disable() is not called, but the device resources\n   are freed by aperture_detach_platform_device()\n3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()\n4. NULL pointer dereference via sysfb_disable() since the resources\n   have already been freed by aperture_detach_platform_device() when\n   it was called by the other device.\r\n\r\nFix this by passing a device pointer to sysfb_disable() and checking\nthe device to determine if we should execute it or not.\r\n\r\nv2: Fix build when CONFIG_SCREEN_INFO is not set\nv3: Move device check into the mutex\n    Drop primary variable in aperture_remove_conflicting_pci_devices()\n    Drop __init on pci sysfb_pci_dev_is_enabled()(CVE-2024-46698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/aux: Fix AUX buffer serialization\r\n\r\nOle reported that event-\u0026gt;mmap_mutex is strictly insufficient to\nserialize the AUX buffer, add a per RB mutex to fully serialize it.\r\n\r\nNote that in the lock order comment the perf_event::mmap_mutex order\nwas already wrong, that is, it nesting under mmap_lock is not new with\nthis patch.(CVE-2024-46713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: protect XDP configuration with a mutex\r\n\r\nThe main threat to data consistency in ice_xdp() is a possible asynchronous\nPF reset. It can be triggered by a user or by TX timeout handler.\r\n\r\nXDP setup and PF reset code access the same resources in the following\nsections:\n* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked\n* ice_vsi_rebuild() for the PF VSI - not protected\n* ice_vsi_open() - already rtnl-locked\r\n\r\nWith an unfortunate timing, such accesses can result in a crash such as the\none below:\r\n\r\n[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14\n[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18\n[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms\n[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001\n[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14\n[ +0.394718] ice 0000:b1:00.0: PTP reset successful\n[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ +0.000045] #PF: supervisor read access in kernel mode\n[ +0.000023] #PF: error_code(0x0000) - not-present page\n[ +0.000023] PGD 0 P4D 0\n[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1\n[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000036] Workqueue: ice ice_service_task [ice]\n[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]\n[...]\n[ +0.000013] Call Trace:\n[ +0.000016] \u0026lt;TASK\u0026gt;\n[ +0.000014] ? __die+0x1f/0x70\n[ +0.000029] ? page_fault_oops+0x171/0x4f0\n[ +0.000029] ? schedule+0x3b/0xd0\n[ +0.000027] ? exc_page_fault+0x7b/0x180\n[ +0.000022] ? asm_exc_page_fault+0x22/0x30\n[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]\n[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]\n[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]\n[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]\n[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]\n[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[ +0.000145] ice_rebuild+0x18c/0x840 [ice]\n[ +0.000145] ? delay_tsc+0x4a/0xc0\n[ +0.000022] ? delay_tsc+0x92/0xc0\n[ +0.000020] ice_do_reset+0x140/0x180 [ice]\n[ +0.000886] ice_service_task+0x404/0x1030 [ice]\n[ +0.000824] process_one_work+0x171/0x340\n[ +0.000685] worker_thread+0x277/0x3a0\n[ +0.000675] ? preempt_count_add+0x6a/0xa0\n[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50\n[ +0.000679] ? __pfx_worker_thread+0x10/0x10\n[ +0.000653] kthread+0xf0/0x120\n[ +0.000635] ? __pfx_kthread+0x10/0x10\n[ +0.000616] ret_from_fork+0x2d/0x50\n[ +0.000612] ? __pfx_kthread+0x10/0x10\n[ +0.000604] ret_from_fork_asm+0x1b/0x30\n[ +0.000604] \u0026lt;/TASK\u0026gt;\r\n\r\nThe previous way of handling this through returning -EBUSY is not viable,\nparticularly when destroying AF_XDP socket, because the kernel proceeds\nwith removal anyway.\r\n\r\nThere is plenty of code between those calls and there is no need to create\na large critical section that covers all of them, same as there is no need\nto protect ice_vsi_rebuild() with rtnl_lock().\r\n\r\nAdd xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().\r\n\r\nLeaving unprotected sections in between would result in two states that\nhave to be considered:\n1. when the VSI is closed, but not yet rebuild\n2. when VSI is already rebuild, but not yet open\r\n\r\nThe latter case is actually already handled through !netif_running() case,\nwe just need to adjust flag checking a little. The former one is not as\ntrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of\nhardware interaction happens, this can make adding/deleting rings exit\nwith an error. Luckily, VSI rebuild is pending and can apply new\nconfiguration for us in a managed fashion.\r\n\r\nTherefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to\nindicate that ice_x\n---truncated---(CVE-2024-46765)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  icmp: change the order of rate limits  ICMP messages are ratelimited :  After the blamed commits, the two rate limiters are applied in this order:  1) host wide ratelimit (icmp_global_allow())  2) Per destination ratelimit (inetpeer based)  In order to avoid side-channels attacks, we need to apply the per destination check first.  This patch makes the following change :  1) icmp_global_allow() checks if the host wide limit is reached.    But credits are not yet consumed. This is deferred to 3)  2) The per destination limit is checked/updated.    This might add a new node in inetpeer tree.  3) icmp_global_consume() consumes tokens if prior operations succeeded.  This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS.  As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.(CVE-2024-47678)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()  Blamed commit accidentally removed a check for rt-\u0026gt;rt6i_idev being NULL, as spotted by syzbot:  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024  RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]  RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df \u0026lt;80\u0026gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;   addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856  addrconf_notify+0x3cb/0x1020   notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93   call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]   call_netdevice_notifiers net/core/dev.c:2046 [inline]   unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352   unregister_netdevice_many net/core/dev.c:11414 [inline]   unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289   unregister_netdevice include/linux/netdevice.h:3129 [inline]   __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685   tun_detach drivers/net/tun.c:701 [inline]   tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510   __fput+0x24a/0x8a0 fs/file_table.c:422   task_work_run+0x24f/0x310 kernel/task_work.c:228   exit_task_work include/linux/task_work.h:40 [inline]   do_exit+0xa2f/0x27f0 kernel/exit.c:882   do_group_exit+0x207/0x2c0 kernel/exit.c:1031   __do_sys_exit_group kernel/exit.c:1042 [inline]   __se_sys_exit_group kernel/exit.c:1040 [inline]   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040   x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0  \u0026lt;/TASK\u0026gt; Modules linked in: ---[ end trace 0000000000000000 ]---  RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]  RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df \u0026lt;80\u0026gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---(CVE-2024-47707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param  In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues.  This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues.  To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param-\u0026gt;tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.(CVE-2024-47712)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm: call the security_mmap_file() LSM hook in remap_file_pages()  The remap_file_pages syscall handler calls do_mmap() directly, which doesn\u0026apos;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.  So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.  The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1].  The PoC:  $ cat \u0026gt; test.c  int main(void) {  size_t pagesz = sysconf(_SC_PAGE_SIZE);  int mfd = syscall(SYS_memfd_create, \u0026quot;test\u0026quot;, 0);  const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,   MAP_SHARED, mfd, 0);  unsigned int old = syscall(SYS_personality, 0xffffffff);  syscall(SYS_personality, READ_IMPLIES_EXEC | old);  syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);  syscall(SYS_personality, old);  // show the RWX page exists even if W^X policy is enforced  int fd = open(\u0026quot;/proc/self/maps\u0026quot;, O_RDONLY);  unsigned char buf2[1024];  while (1) {   int ret = read(fd, buf2, 1024);   if (ret \u0026lt;= 0) break;   write(1, buf2, ret);  }  close(fd); }  $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)  [PM: subject line tweaks](CVE-2024-47745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition  In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to \u0026amp;prev(dev)-\u0026gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                    CPU1                        |  ether3_ledoff ether3_remove         |   free_netdev(dev);   |   put_devic           |   kfree(dev);         |  |  ether3_outw(priv(dev)-\u0026gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2);                       | // use dev  Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/cxgb4: Added NULL check for lookup_atid  The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/sgx: Fix deadlock in SGX NUMA node search  When the current node doesn\u0026apos;t have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask.  Also worth mentioning is that it\u0026apos;s perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality.  Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.(CVE-2024-49856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm, slub: avoid zeroing kmalloc redzone  Since commit 946fa0dbf2d8 (\u0026quot;mm/slub: extend redzone check to extra allocated kmalloc space than requested\u0026quot;), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object-\u0026gt;size, including the redzone.  Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone.  These issues lead to the following BUG report with \u0026quot;slub_debug=FUZ init_on_free=1\u0026quot;:  [    0.000000] ============================================================================= [    0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [    0.000000] ----------------------------------------------------------------------------- [    0.000000] [    0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [    0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [    0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [    0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [    0.000000] [    0.000000] Redzone  ffff000010032850: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Object   ffff000010032858: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Redzone  ffff000010032860: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Padding  ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00              ............ [    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [    0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [    0.000000] Call trace: [    0.000000]  dump_backtrace+0x90/0xe8 [    0.000000]  show_stack+0x18/0x24 [    0.000000]  dump_stack_lvl+0x74/0x8c [    0.000000]  dump_stack+0x18/0x24 [    0.000000]  print_trailer+0x150/0x218 [    0.000000]  check_object+0xe4/0x454 [    0.000000]  free_to_partial_list+0x2f8/0x5ec  To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area.  When CONFIG_SLUB_DEBUG not defined, (get_orig_size()\u0026apos; directly returns s-\u0026gt;object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.(CVE-2024-49885)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize denominators\u0026apos; default to 1  [WHAT \u0026amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe  This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx-\u0026gt;plane_state` is null.  The fix adds a check to ensure `pipe_ctx-\u0026gt;plane_state` is not null before accessing. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed \u0026apos;pipe_ctx-\u0026gt;plane_state\u0026apos; could be null (see line 1877)(CVE-2024-49914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc-\u0026gt;clk_mgr` is null.  The fix adds a check to ensure `dc-\u0026gt;clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed \u0026apos;dc-\u0026gt;clk_mgr\u0026apos; could be null (see line 782)(CVE-2024-49915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: Fix an unsafe loop on the list  The kernel may crash when deleting a genetlink family if there are still listeners for that family:  Oops: Kernel access of bad area, sig: 11 [#1]   ...   NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0   LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0   Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0  Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.(CVE-2024-50024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/v3d: Stop the active perfmon before being destroyed  When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur:  [   55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [   55.008368] Mem abort info: [   55.008377]   ESR = 0x0000000096000005 [   55.008387]   EC = 0x25: DABT (current EL), IL = 32 bits [   55.008402]   SET = 0, FnV = 0 [   55.008412]   EA = 0, S1PTW = 0 [   55.008421]   FSC = 0x05: level 1 translation fault [   55.008434] Data abort info: [   55.008442]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [   55.008455]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [   55.008467]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [   55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [   55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [   55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [   55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [   55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G         C         6.6.47+rpt-rpi-v8 #1  Debian 1:6.6.47-1+rpt1 [   55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [   55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [   55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [   55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [   55.008895] sp : ffffffc080673cf0 [   55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [   55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [   55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [   55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [   55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [   55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [   55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [   55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [   55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [   55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [   55.013292] Call trace: [   55.013959]  __mutex_lock.constprop.0+0x90/0x608 [   55.014646]  __mutex_lock_slowpath+0x1c/0x30 [   55.015317]  mutex_lock+0x50/0x68 [   55.015961]  v3d_perfmon_stop+0x40/0xe0 [v3d] [   55.016627]  v3d_bin_job_run+0x10c/0x2d8 [v3d] [   55.017282]  drm_sched_main+0x178/0x3f8 [gpu_sched] [   55.017921]  kthread+0x11c/0x128 [   55.018554]  ret_from_fork+0x10/0x20 [   55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [   55.019776] ---[ end trace 0000000000000000 ]--- [   55.020411] note: v3d_bin[166] exited with preempt_count 1  This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor\u0026apos;s pointer (`v3d-\u0026gt;active_perfmon`) is still retained.  If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d-\u0026gt;active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed.  To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: xtables: avoid NFPROTO_UNSPEC where needed  syzbot managed to call xt_cluster match via ebtables:   WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780  [..]  ebt_do_table+0x174b/0x2a40  Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing.  As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only.  Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables.  Check all UNSPEC matches and targets for similar issues:  - matches and targets are fine except if they assume skb_network_header()   is valid -- this is only true when called from inet layer: ip(6) stack   pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be   restricted too, they are incompatbile with the ebtables traverser, e.g.   EBT_CONTINUE is a completely different value than XT_CONTINUE.  Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables.  The MARK target is also used by arptables, so register for NFPROTO_ARP too.  While at it, bail out if connbytes fails to enable the corresponding conntrack family.  This change passes the selftests in iptables.git.(CVE-2024-50038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/sched: accept TCA_STAB only for root qdisc  Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers.  Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1]  We can\u0026apos;t support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage.  [1] [   88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   88.798611] #PF: supervisor read access in kernel mode [   88.799014] #PF: error_code(0x0000) - not-present page [   88.799506] PGD 0 P4D 0 [   88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [   88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [   88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a \u0026lt;4c\u0026gt; 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ========    0: 0f b7 50 12           movzwl 0x12(%rax),%edx    4: 48 8d 04 d5 00 00 00  lea    0x0(,%rdx,8),%rax    b: 00    c: 48 89 d6              mov    %rdx,%rsi    f: 48 29 d0              sub    %rdx,%rax   12: 48 8b 91 c0 01 00 00  mov    0x1c0(%rcx),%rdx   19: 48 c1 e0 03           shl    $0x3,%rax   1d: 48 01 c2              add    %rax,%rdx   20: 66 83 7a 1a 00        cmpw   $0x0,0x1a(%rdx)   25: 7e c0                 jle    0xffffffffffffffe7   27: 48 8b 3a              mov    (%rdx),%rdi   2a:* 4c 8b 07              mov    (%rdi),%r8  \u0026lt;-- trapping instruction   2d: 4c 89 02              mov    %r8,(%rdx)   30: 49 89 50 08           mov    %rdx,0x8(%r8)   34: 48 c7 47 08 00 00 00  movq   $0x0,0x8(%rdi)   3b: 00   3c: 48                    rex.W   3d: c7                    .byte 0xc7   3e: 07                    (bad)  ...  Code starting with the faulting instruction ===========================================    0: 4c 8b 07              mov    (%rdi),%r8    3: 4c 89 02              mov    %r8,(%rdx)    6: 49 89 50 08           mov    %rdx,0x8(%r8)    a: 48 c7 47 08 00 00 00  movq   $0x0,0x8(%rdi)   11: 00   12: 48                    rex.W   13: c7                    .byte 0xc7   14: 07                    (bad)  ... [   88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [   88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [   88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [   88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [   88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [   88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [   88.806734] FS:  00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [   88.807225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [   88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [   88.808165] Call Trace: [   88.808459]  \u0026lt;TASK\u0026gt; [   88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [   88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [   88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [   88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [   88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [   88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [   88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---(CVE-2024-50039)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: br_netfilter: fix panic with metadata_dst skb  Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit.  It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded  When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-\u0026gt;dst.dev is NULL.  Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there\u0026apos;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu.  The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-\u0026gt;dev, thus the crash.  This case was never supported in the first place, so drop the packet instead.  PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [  176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [  176.292101] Mem abort info: [  176.292184]   ESR = 0x0000000096000004 [  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits [  176.292530]   SET = 0, FnV = 0 [  176.292709]   EA = 0, S1PTW = 0 [  176.292862]   FSC = 0x04: level 0 translation fault [  176.293013] Data abort info: [  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [  176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [  176.296314] Hardware name: linux,dummy-virt (DT) [  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [  176.297636] sp : ffff800080003630 [  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [  176.300889] Call trace: [  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [  176.301703]  nf_hook_slow+0x48/0x124 [  176.302060]  br_forward_finish+0xc8/0xe8 [bridge] [  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter] [  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter] [  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter] [  176.303359]  nf_hook_slow+0x48/0x124 [  176.303 ---truncated---(CVE-2024-50045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-srv: Avoid null pointer deref during path establishment  For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED.  So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow  Syzkaller reported this splat:    ==================================================================   BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881   Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662    CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0xc3/0x620 mm/kasan/report.c:488    kasan_report+0xd9/0x110 mm/kasan/report.c:601    mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881    mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]    mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572    mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603    genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115    genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]    genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210    netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551    genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219    netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]    netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357    netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901    sock_sendmsg_nosec net/socket.c:729 [inline]    __sock_sendmsg net/socket.c:744 [inline]    ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607    ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661    __sys_sendmsg+0x117/0x1f0 net/socket.c:2690    do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]    __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386    do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411    entry_SYSENTER_compat_after_hwframe+0x84/0x8e   RIP: 0023:0xf7fe4579   Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 \u0026lt;5d\u0026gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00   RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172   RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140   RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000   RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000   R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000   R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000    \u0026lt;/TASK\u0026gt;    Allocated by task 5387:    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47    kasan_save_track+0x14/0x30 mm/kasan/common.c:68    poison_kmalloc_redzone mm/kasan/common.c:377 [inline]    __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394    kmalloc_noprof include/linux/slab.h:878 [inline]    kzalloc_noprof include/linux/slab.h:1014 [inline]    subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803    subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956    __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]    tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167    mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764    __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592    mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642    mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]    mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943    mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777    process_one_work+0x958/0x1b30 kernel/workqueue.c:3229    process_scheduled_works kernel/workqueue.c:3310 [inline]    worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391    kthread+0x2c1/0x3a0 kernel/kthread.c:389    ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  thermal: intel: int340x: processor: Fix warning during module unload  The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach.  Thus there is no need to call pci_disable_device() again on it.  With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\u0026quot;PCI: Remove legacy pcim_release()\u0026quot;), this problem is exposed and triggers the warining below.   [  224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device  [  224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100  ...  [  224.010844] Call Trace:  [  224.010845]  \u0026lt;TASK\u0026gt;  [  224.010847]  ? show_regs+0x6d/0x80  [  224.010851]  ? __warn+0x8c/0x140  [  224.010854]  ? pci_disable_device+0xe5/0x100  [  224.010856]  ? report_bug+0x1c9/0x1e0  [  224.010859]  ? handle_bug+0x46/0x80  [  224.010862]  ? exc_invalid_op+0x1d/0x80  [  224.010863]  ? asm_exc_invalid_op+0x1f/0x30  [  224.010867]  ? pci_disable_device+0xe5/0x100  [  224.010869]  ? pci_disable_device+0xe5/0x100  [  224.010871]  ? kfree+0x21a/0x2b0  [  224.010873]  pcim_disable_device+0x20/0x30  [  224.010875]  devm_action_release+0x16/0x20  [  224.010878]  release_nodes+0x47/0xc0  [  224.010880]  devres_release_all+0x9f/0xe0  [  224.010883]  device_unbind_cleanup+0x12/0x80  [  224.010885]  device_release_driver_internal+0x1ca/0x210  [  224.010887]  driver_detach+0x4e/0xa0  [  224.010889]  bus_remove_driver+0x6f/0xf0  [  224.010890]  driver_unregister+0x35/0x60  [  224.010892]  pci_unregister_driver+0x44/0x90  [  224.010894]  proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci]  ...  [  224.010921] ---[ end trace 0000000000000000 ]---  Remove the excess pci_disable_device() calls.  [ rjw: Subject and changelog edits ](CVE-2024-50093)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down  There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU\u0026apos;s scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error.  [   31.907781]I[0:      swapper/0:    0]        1        130705007       1651079834      11289729804                0 D(   2) 3 ffffff882e208000 *             init [device_shutdown] [   31.907793]I[0:      swapper/0:    0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [   31.907806]I[0:      swapper/0:    0] Call trace: [   31.907810]I[0:      swapper/0:    0]  __switch_to+0x174/0x338 [   31.907819]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc [   31.907826]I[0:      swapper/0:    0]  schedule+0x7c/0xe8 [   31.907834]I[0:      swapper/0:    0]  schedule_preempt_disabled+0x24/0x40 [   31.907842]I[0:      swapper/0:    0]  __mutex_lock+0x408/0xdac [   31.907849]I[0:      swapper/0:    0]  __mutex_lock_slowpath+0x14/0x24 [   31.907858]I[0:      swapper/0:    0]  mutex_lock+0x40/0xec [   31.907866]I[0:      swapper/0:    0]  device_shutdown+0x108/0x280 [   31.907875]I[0:      swapper/0:    0]  kernel_restart+0x4c/0x11c [   31.907883]I[0:      swapper/0:    0]  __arm64_sys_reboot+0x15c/0x280 [   31.907890]I[0:      swapper/0:    0]  invoke_syscall+0x70/0x158 [   31.907899]I[0:      swapper/0:    0]  el0_svc_common+0xb4/0xf4 [   31.907909]I[0:      swapper/0:    0]  do_el0_svc+0x2c/0xb0 [   31.907918]I[0:      swapper/0:    0]  el0_svc+0x34/0xe0 [   31.907928]I[0:      swapper/0:    0]  el0t_64_sync_handler+0x68/0xb4 [   31.907937]I[0:      swapper/0:    0]  el0t_64_sync+0x1a0/0x1a4  [   31.908774]I[0:      swapper/0:    0]       49                0         11960702      11236868007                0 D(   2) 6 ffffff882e28cb00 *      kworker/6:0 [__bio_queue_enter] [   31.908783]I[0:      swapper/0:    0] Call trace: [   31.908788]I[0:      swapper/0:    0]  __switch_to+0x174/0x338 [   31.908796]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc [   31.908803]I[0:      swapper/0:    0]  schedule+0x7c/0xe8 [   31.908811]I[0:      swapper/0:    0]  __bio_queue_enter+0xb8/0x178 [   31.908818]I[0:      swapper/0:    0]  blk_mq_submit_bio+0x194/0x67c [   31.908827]I[0:      swapper/0:    0]  __submit_bio+0xb8/0x19c(CVE-2024-50098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context  PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services.  The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called.      [Firmware Bug]: Unable to handle paging request in EFI runtime service     WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341         __efi_queue_work+0x11c/0x170     Call trace:  Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context.  If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler.  However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling.  By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error.  The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute.  [ rjw: Subject and changelog edits ](CVE-2024-50141)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  udf: fix uninit-value use in udf_get_fileshortad  Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2].  [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: bnep: fix wild-memory-access in proto_unregister  There\u0026apos;s issue as follows:   KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]   CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W   RIP: 0010:proto_unregister+0xee/0x400   Call Trace:    \u0026lt;TASK\u0026gt;    __do_sys_delete_module+0x318/0x580    do_syscall_64+0xc1/0x1d0    entry_SYSCALL_64_after_hwframe+0x77/0x7f  As bnep_init() ignore bnep_sock_init()\u0026apos;s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock\u0026apos;s resource. To solve above issue just return bnep_sock_init()\u0026apos;s return value in bnep_exit().(CVE-2024-50148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink().  Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().    \u0026quot;\u0026quot;\u0026quot;   We are seeing a use-after-free from a bpf prog attached to   trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the   bpf_sk_storage_get_tracing kernel helper which does check for null   before using it.   \u0026quot;\u0026quot;\u0026quot;  The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.  Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending.  If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.  The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default.  The scenario would be    1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),      but del_timer_sync() is missed    2. reqsk timer is executed and scheduled again    3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but      reqsk timer still has another one, and inet_csk_accept() does not      clear req-\u0026gt;sk for non-TFO sockets    4. sk is close()d    5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk  Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().  Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]  [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0  Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6  allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop  Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high.  Add a loop count for FPGA and exit the __wait_for_fifo_occupancy_below_th if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxt_re_pacing_timer_exp and further scheduling the work for pacing based on the fifo occupancy.(CVE-2024-50157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: devmap: provide rxq after redirect  rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set.  This is particularly bad since accessing ingress_ifindex, e.g.  SEC(\u0026quot;xdp\u0026quot;) int prog(struct xdp_md *pkt) {         return bpf_redirect_map(\u0026amp;dev_redirect_map, 0, 0); }  SEC(\u0026quot;xdp/devmap\u0026quot;) int prog_after_redirect(struct xdp_md *pkt) {         bpf_printk(\u0026quot;ifindex %i\u0026quot;, pkt-\u0026gt;ingress_ifindex);         return XDP_PASS; }  depends on access to rxq, so a NULL pointer gets dereferenced:  \u0026lt;1\u0026gt;[  574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 \u0026lt;1\u0026gt;[  574.475188] #PF: supervisor read access in kernel mode \u0026lt;1\u0026gt;[  574.475194] #PF: error_code(0x0000) - not-present page \u0026lt;6\u0026gt;[  574.475199] PGD 0 P4D 0 \u0026lt;4\u0026gt;[  574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI \u0026lt;4\u0026gt;[  574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 \u0026lt;4\u0026gt;[  574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 \u0026lt;4\u0026gt;[  574.475231] Workqueue: mld mld_ifc_work \u0026lt;4\u0026gt;[  574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c \u0026lt;4\u0026gt;[  574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 \u0026lt;48\u0026gt; 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b \u0026lt;4\u0026gt;[  574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 \u0026lt;4\u0026gt;[  574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 \u0026lt;4\u0026gt;[  574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 \u0026lt;4\u0026gt;[  574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 \u0026lt;4\u0026gt;[  574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 \u0026lt;4\u0026gt;[  574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 \u0026lt;4\u0026gt;[  574.475289] FS:  0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 \u0026lt;4\u0026gt;[  574.475294] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 \u0026lt;4\u0026gt;[  574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 \u0026lt;4\u0026gt;[  574.475303] PKRU: 55555554 \u0026lt;4\u0026gt;[  574.475306] Call Trace: \u0026lt;4\u0026gt;[  574.475313]  \u0026lt;IRQ\u0026gt; \u0026lt;4\u0026gt;[  574.475318]  ? __die+0x23/0x70 \u0026lt;4\u0026gt;[  574.475329]  ? page_fault_oops+0x180/0x4c0 \u0026lt;4\u0026gt;[  574.475339]  ? skb_pp_cow_data+0x34c/0x490 \u0026lt;4\u0026gt;[  574.475346]  ? kmem_cache_free+0x257/0x280 \u0026lt;4\u0026gt;[  574.475357]  ? exc_page_fault+0x67/0x150 \u0026lt;4\u0026gt;[  574.475368]  ? asm_exc_page_fault+0x26/0x30 \u0026lt;4\u0026gt;[  574.475381]  ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c \u0026lt;4\u0026gt;[  574.475386]  bq_xmit_all+0x158/0x420 \u0026lt;4\u0026gt;[  574.475397]  __dev_flush+0x30/0x90 \u0026lt;4\u0026gt;[  574.475407]  veth_poll+0x216/0x250 [veth] \u0026lt;4\u0026gt;[  574.475421]  __napi_poll+0x28/0x1c0 \u0026lt;4\u0026gt;[  574.475430]  net_rx_action+0x32d/0x3a0 \u0026lt;4\u0026gt;[  574.475441]  handle_softirqs+0xcb/0x2c0 \u0026lt;4\u0026gt;[  574.475451]  do_softirq+0x40/0x60 \u0026lt;4\u0026gt;[  574.475458]  \u0026lt;/IRQ\u0026gt; \u0026lt;4\u0026gt;[  574.475461]  \u0026lt;TASK\u0026gt; \u0026lt;4\u0026gt;[  574.475464]  __local_bh_enable_ip+0x66/0x70 \u0026lt;4\u0026gt;[  574.475471]  __dev_queue_xmit+0x268/0xe40 \u0026lt;4\u0026gt;[  574.475480]  ? selinux_ip_postroute+0x213/0x420 \u0026lt;4\u0026gt;[  574.475491]  ? alloc_skb_with_frags+0x4a/0x1d0 \u0026lt;4\u0026gt;[  574.475502]  ip6_finish_output2+0x2be/0x640 \u0026lt;4\u0026gt;[  574.475512]  ? nf_hook_slow+0x42/0xf0 \u0026lt;4\u0026gt;[  574.475521]  ip6_finish_output+0x194/0x300 \u0026lt;4\u0026gt;[  574.475529]  ? __pfx_ip6_finish_output+0x10/0x10 \u0026lt;4\u0026gt;[  574.475538]  mld_sendpack+0x17c/0x240 \u0026lt;4\u0026gt;[  574.475548]  mld_ifc_work+0x192/0x410 \u0026lt;4\u0026gt;[  574.475557]  process_one_work+0x15d/0x380 \u0026lt;4\u0026gt;[  574.475566]  worker_thread+0x29d/0x3a0 \u0026lt;4\u0026gt;[  574.475573]  ? __pfx_worker_thread+0x10/0x10 \u0026lt;4\u0026gt;[  574.475580]  ? __pfx_worker_thread+0x10/0x10 \u0026lt;4\u0026gt;[  574.475587]  kthread+0xcd/0x100 \u0026lt;4\u0026gt;[  574.475597]  ? __pfx_kthread+0x10/0x10 \u0026lt;4\u0026gt;[  574.475606]  ret_from_fork+0x31/0x50 \u0026lt;4\u0026gt;[  574.475615]  ? __pfx_kthread+0x10/0x10 \u0026lt;4\u0026gt;[  574.475623]  ret_from_fork_asm+0x1a/0x ---truncated---(CVE-2024-50162)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fsl/fman: Fix refcount handling of fman-related devices  In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev-\u0026gt;dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks.  Add references release.(CVE-2024-50166)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vsock: Update rx_bytes on read_skb()  Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt() calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn\u0026apos;t lie) after vsock_transport::read_skb().  While here, also inform the peer that we\u0026apos;ve freed up space and it has more credit.  Failing to update rx_bytes after packet is dequeued leads to a warning on SOCK_STREAM recv():  [  233.396654] rx_queue is empty, but rx_bytes is non-zero [  233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589(CVE-2024-50169)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: bcmasp: fix potential memory leak in bcmasp_xmit()  The bcmasp_xmit() returns NETDEV_TX_OK without freeing skb in case of mapping fails, add dev_kfree_skb() to fix it.(CVE-2024-50170)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: systemport: fix potential memory leak in bcm_sysport_xmit()  The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.(CVE-2024-50171)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  secretmem: disable memfd_secret() if arch cannot set direct map  Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM\u0026apos;s break-before-make semantics do not easily allow breaking apart large/gigantic pages).  More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error.  This means that memfd_secret will seemingly \u0026quot;work\u0026quot; (e.g.  syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map.  Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to \u0026apos;y\u0026apos;, most arm64 systems actually have a working memfd_secret() and aren\u0026apos;t be affected.  From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations.  [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/(CVE-2024-50182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: don\u0026apos;t set SB_RDONLY after filesystem errors  When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb-\u0026gt;s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn\u0026apos;t be needed. So stop doing that.(CVE-2024-50191)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  irqchip/gic-v4: Don\u0026apos;t allow a VMOVP on a dying VPE  Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/.  Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case.  This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  posix-clock: Fix missing timespec64 check in pc_clock_settime()  As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct\u0026apos;s tv_sec and tv_nsec range before calling ptp-\u0026gt;info-\u0026gt;settime64().  As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid.  There are some drivers that use tp-\u0026gt;tv_sec and tp-\u0026gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf, arm64: Fix address emission with tag-based KASAN enabled  When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission.(CVE-2024-50203)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()  The step variable is initialized to zero. It is changed in the loop, but if it\u0026apos;s not changed it will remain zero. Add a variable check before the division.  The observed behavior was introduced by commit 826b5de90c0b (\u0026quot;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\u0026quot;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages  Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages \u0026gt; 256K.  There will be a single PDE page address (contiguous pages in the case of \u0026gt; PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.(CVE-2024-50208)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Add a check for memory allocation  __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.(CVE-2024-50209)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  xfs: fix finding a last resort AG in xfs_filestream_pick_ag  When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG.  But the loop for that uses args-\u0026gt;pag as loop iterator while the later code expects pag to be set.  Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn\u0026apos;t even escape in theory.(CVE-2024-50216)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()  Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable \u0026apos;device-\u0026gt;bdev_file\u0026apos; in __btrfs_free_extra_devids(). And following are the details:  1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs    devices by ioctl(BTRFS_IOC_SCAN_DEV):               /  btrfs_device_1 \u2192 loop0    fs_device              \\  btrfs_device_2 \u2192 loop1 2. mount /dev/loop0 /mnt    btrfs_open_devices     btrfs_device_1-\u0026gt;bdev_file = btrfs_get_bdev_and_sb(loop0)     btrfs_device_2-\u0026gt;bdev_file = btrfs_get_bdev_and_sb(loop1)    btrfs_fill_super     open_ctree      fail: btrfs_close_devices // -ENOMEM      btrfs_close_bdev(btrfs_device_1)              fput(btrfs_device_1-\u0026gt;bdev_file)        // btrfs_device_1-\u0026gt;bdev_file is freed      btrfs_close_bdev(btrfs_device_2)              fput(btrfs_device_2-\u0026gt;bdev_file)  3. mount /dev/loop1 /mnt    btrfs_open_devices     btrfs_get_bdev_and_sb(\u0026amp;bdev_file)      // EIO, btrfs_device_1-\u0026gt;bdev_file is not assigned,      // which points to a freed memory area     btrfs_device_2-\u0026gt;bdev_file = btrfs_get_bdev_and_sb(loop1)    btrfs_fill_super     open_ctree      btrfs_free_extra_devids       if (btrfs_device_1-\u0026gt;bdev_file)        fput(btrfs_device_1-\u0026gt;bdev_file) // UAF !  Fix it by setting \u0026apos;device-\u0026gt;bdev_file\u0026apos; as \u0026apos;NULL\u0026apos; after closing the btrfs_device in btrfs_close_one_device().(CVE-2024-50217)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sched/numa: Fix the potential null pointer dereference in task_numa_work()  When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace:    [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020   ......   [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se   ......   [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)   [323676.067115] pc : vma_migratable+0x1c/0xd0   [323676.067122] lr : task_numa_work+0x1ec/0x4e0   [323676.067127] sp : ffff8000ada73d20   [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010   [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000   [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000   [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8   [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035   [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8   [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4   [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001   [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000   [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000   [323676.067152] Call trace:   [323676.067153]  vma_migratable+0x1c/0xd0   [323676.067155]  task_numa_work+0x1ec/0x4e0   [323676.067157]  task_work_run+0x78/0xd8   [323676.067161]  do_notify_resume+0x1ec/0x290   [323676.067163]  el0_svc+0x150/0x160   [323676.067167]  el0t_64_sync_handler+0xf8/0x128   [323676.067170]  el0t_64_sync+0x17c/0x180   [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)   [323676.067177] SMP: stopping secondary CPUs   [323676.070184] Starting crashdump kernel...  stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process.  Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0.  Recheck the vma pointer before dereferencing it in task_numa_work().(CVE-2024-50223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix kernel bug due to missing clearing of checked flag  Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug.  This was found to be because the \u0026quot;checked\u0026quot; flag of a page/folio was not cleared when it was discarded by nilfs2\u0026apos;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded.  So, fix that.  This was necessary when the use of nilfs2\u0026apos;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: iwlegacy: Clear stale interrupts before resuming device  iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn\u0026apos;t being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.  Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.  Here\u0026apos;s a debug log of the indicent: [   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [   12.042653] iwl4965 0000:10:00.0: On demand firmware reload [   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [   12.052207] ieee80211 phy0: il4965_mac_start enter [   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready [   12.052324] ieee80211 phy0: il_apm_init Init card\u0026apos;s basic functions [   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [   12.058827] ieee80211 phy0: _il_apm_stop_master stop master [   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [   12.058869] ieee80211 phy0: Hardware restart was requested [   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [   16.132303] ------------[ cut here ]------------ [   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [   16.132463] Workqueue: async async_run_entry_fn [   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [   16.132501] Code: da 02 00 0 ---truncated---(CVE-2024-50234)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: ath10k: Fix memory leak in management tx  In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic.  Kmemleak reports this problem as below,  unreferenced object 0xffffff80b64ed250 (size 16):   comm \u0026quot;kworker/u16:7\u0026quot;, pid 148, jiffies 4294687130 (age 714.199s)   hex dump (first 16 bytes):     00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......   backtrace:     [\u0026lt;ffffffe6e7b245dc\u0026gt;] __kmem_cache_alloc_node+0x1e4/0x2d8     [\u0026lt;ffffffe6e7adde88\u0026gt;] kmalloc_trace+0x48/0x110     [\u0026lt;ffffffe6bbd765fc\u0026gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]     [\u0026lt;ffffffe6bbd3eed4\u0026gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]     [\u0026lt;ffffffe6e78d5974\u0026gt;] process_scheduled_works+0x1ac/0x400     [\u0026lt;ffffffe6e78d60b8\u0026gt;] worker_thread+0x208/0x328     [\u0026lt;ffffffe6e78dc890\u0026gt;] kthread+0x100/0x1c0     [\u0026lt;ffffffe6e78166c0\u0026gt;] ret_from_fork+0x10/0x20  Free the memory during completion and cleanup to fix the leak.  Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-\u0026gt;data_lock similar to other instances.  Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1(CVE-2024-50236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Initialize struct nfsd4_copy earlier  Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don\u0026apos;t stray beyond valid memory region.(CVE-2024-50248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs  Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.  __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn\u0026apos;t exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb-\u0026gt;data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb-\u0026gt;data[0].  KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 \u0026lt;0f\u0026gt; b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS:  0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace:  \u0026lt;TASK\u0026gt;  hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline]  hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline]  hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline]  hci_init_sync net/bluetooth/hci_sync.c:4742 [inline]  hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]  hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994  hci_dev_do_open net/bluetooth/hci_core.c:483 [inline]  hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015  process_one_work kernel/workqueue.c:3267 [inline]  process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348  worker_thread+0x91f/0xe50 kernel/workqueue.c:3429  kthread+0x2cb/0x360 kernel/kthread.c:388  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-50255)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: fix crash when config small gso_max_size/gso_ipv4_max_size  Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk-\u0026gt;sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit     tso_segs = tcp_init_tso_segs(skb, mss_now);         tcp_set_skb_tso_segs             tcp_skb_pcount_set                 // skb-\u0026gt;len = 524288, mss_now = 8                 // u16 tso_segs = 524288/8 = 65535 -\u0026gt; 0                 tso_segs = DIV_ROUND_UP(skb-\u0026gt;len, mss_now)     BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.(CVE-2024-50258)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fix out-of-bounds write in trie_get_next_key()  trie_get_next_key() allocates a node stack with size trie-\u0026gt;max_prefixlen, while it writes (trie-\u0026gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()  Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():  [   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry [   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [   57.331328] Call Trace: [   57.331477]  \u0026lt;TASK\u0026gt; [...] [   57.333511]  ? do_user_addr_fault+0x3e5/0x740 [   57.333778]  ? exc_page_fault+0x70/0x170 [   57.334016]  ? asm_exc_page_fault+0x2b/0x30 [   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0 [   57.335164]  ocfs2_xa_set+0x704/0xcf0 [   57.335381]  ? _raw_spin_unlock+0x1a/0x40 [   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20 [   57.335915]  ? trace_preempt_on+0x1e/0x70 [   57.336153]  ? start_this_handle+0x16c/0x500 [   57.336410]  ? preempt_count_sub+0x50/0x80 [   57.336656]  ? _raw_read_unlock+0x20/0x40 [   57.336906]  ? start_this_handle+0x16c/0x500 [   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0 [   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0 [   57.337706]  ? ocfs2_start_trans+0x13d/0x290 [   57.337971]  ocfs2_xattr_set+0xb13/0xfb0 [   57.338207]  ? dput+0x46/0x1c0 [   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30 [   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30 [   57.338948]  __vfs_removexattr+0x92/0xc0 [   57.339182]  __vfs_removexattr_locked+0xd5/0x190 [   57.339456]  ? preempt_count_sub+0x50/0x80 [   57.339705]  vfs_removexattr+0x5f/0x100 [...]  Reproducer uses faultinject facility to fail ocfs2_xa_remove() -\u0026gt; ocfs2_xa_value_truncate() with -ENOMEM.  In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following \u0026apos;rc\u0026apos; check is wrong and execution flow do \u0026apos;ocfs2_xa_remove_entry(loc);\u0026apos; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to \u0026apos;out\u0026apos;.  Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: musb: sunxi: Fix accessing an released usb phy  Commit 6ed05c68cbca (\u0026quot;usb: musb: sunxi: Explicitly release USB PHY on exit\u0026quot;) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released.  1) register platform driver @sunxi_musb_driver // get the usb phy @glue-\u0026gt;xceiv sunxi_musb_probe() -\u0026gt; devm_usb_get_phy().  2) register and unregister platform driver @musb_driver musb_probe() -\u0026gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy()  3) register @musb_driver again musb_probe() -\u0026gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ...  Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  signal: restore the override_rlimit logic  Prior to commit d64696905554 (\u0026quot;Reimplement RLIMIT_SIGPENDING on top of ucounts\u0026quot;) UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals.  However now it\u0026apos;s enforced unconditionally, even if override_rlimit is set.  This behavior change caused production issues.    For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo.  This prevents the process from correctly identifying the fault address and handling the error.  From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively \u0026apos;corrupted\u0026apos;.  This can lead to unpredictable behavior and crashes, as we observed with java applications.  Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set.  This effectively restores the old behavior.(CVE-2024-50271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  filemap: Fix bounds checking in filemap_read()  If the caller supplies an iocb-\u0026gt;ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop.  This behaviour was discovered when testing xfstests generic/525 with the \u0026quot;localio\u0026quot; optimisation for loopback NFS mounts.(CVE-2024-50272)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: reinitialize delayed ref list after deleting it from the list  At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively.  If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise.  So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  arm64/sve: Discard stale CPU state when handling SVE traps  The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set:  |         if (test_and_set_thread_flag(TIF_SVE)) |                 WARN_ON(1); /* SVE access shouldn\u0026apos;t have trapped */  Warnings of this form have been reported intermittently, e.g.    https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/   https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/  The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g.  | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { |         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled |         // task-\u0026gt;fpsimd_cpu is 0. |         // per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is task. | |         ... | |         // Preempted; migrated from CPU 0 to CPU 1. |         // TIF_FOREIGN_FPSTATE is set. | |         get_cpu_fpsimd_context(); | |         if (test_and_set_thread_flag(TIF_SVE)) |                 WARN_ON(1); /* SVE access shouldn\u0026apos;t have trapped */ | |         sve_init_regs() { |                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { |                         ... |                 } else { |                         fpsimd_to_sve(current); |                         current-\u0026gt;thread.fp_type = FP_STATE_SVE; |                 } |         } | |         put_cpu_fpsimd_context(); | |         // Preempted; migrated from CPU 1 to CPU 0. |         // task-\u0026gt;fpsimd_cpu is still 0 |         // If per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is still task then: |         // - Stale HW state is reused (with SVE traps enabled) |         // - TIF_FOREIGN_FPSTATE is cleared |         // - A return to userspace skips HW state restore | }  Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.(CVE-2024-50275)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: vertexcom: mse102x: Fix possible double free of TX skb  The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes:    Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP   CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G      D            6.6.23   Hardware name: chargebyte Charge SOM DC-ONE (DT)   Workqueue: events mse102x_tx_work [mse102x]   pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)   pc : skb_release_data+0xb8/0x1d8   lr : skb_release_data+0x1ac/0x1d8   sp : ffff8000819a3cc0   x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0   x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff   x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50   x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc   x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000   x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000   x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8   x8 : fffffc00001bc008   x7 : 0000000000000000 x6 : 0000000000000008   x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009   x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000   Call trace:    skb_release_data+0xb8/0x1d8    kfree_skb_reason+0x48/0xb0    mse102x_tx_work+0x164/0x35c [mse102x]    process_one_work+0x138/0x260    worker_thread+0x32c/0x438    kthread+0x118/0x11c    ret_from_fork+0x10/0x20   Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)(CVE-2024-50276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp  ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().(CVE-2024-50283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ksmbd: Fix the missing xa_store error check  xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.(CVE-2024-50284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: av7110: fix a spectre vulnerability  As warned by smatch:  drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue \u0026apos;av7110-\u0026gt;ci_slot\u0026apos; [w] (local cap)  There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix missing locking causing hanging calls  If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local-\u0026gt;new_client_calls by rxrpc_disconnect_client_call() without a lock being held.  This may cause other calls on the list to disappear if a race occurs.  Fix this by taking the client_call_lock when removing a call from whatever list its -\u0026gt;wait_link happens to be on.(CVE-2024-50294)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: enetc: allocate vf_state during PF probes  In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows.  root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [  173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [  173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [  173.641973] lr : do_setlink+0x4a8/0xec8 [  173.732292] Call trace: [  173.734740]  enetc_pf_set_vf_mac+0x3c/0x80 [  173.738847]  __rtnl_newlink+0x530/0x89c [  173.742692]  rtnl_newlink+0x50/0x7c [  173.746189]  rtnetlink_rcv_msg+0x128/0x390 [  173.750298]  netlink_rcv_skb+0x60/0x130 [  173.754145]  rtnetlink_rcv+0x18/0x24 [  173.757731]  netlink_unicast+0x318/0x380 [  173.761665]  netlink_sendmsg+0x17c/0x3c8(CVE-2024-50298)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sctp: properly validate chunk size in sctp_sf_ootb()  A size validation fix similar to that in Commit 50619dbf8db7 (\u0026quot;sctp: add size validation when walking chunks\u0026quot;) is also required in sctp_sf_ootb() to address a crash reported by syzbot:    BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712   sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712   sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166   sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88   sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243   sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159   ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205   ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233(CVE-2024-50299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mctp i2c: handle NULL header address  daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped.  saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.(CVE-2024-53043)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  arm64: dts: imx8ulp: correct the flexspi compatible string  The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error:  [    1.119072] ------------[ cut here ]------------ [    1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [    1.133239] Modules linked in: [    1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [    1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [    1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [    1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [    1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [    1.168060] sp : ffff80008002b2a0 [    1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [    1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [    1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [    1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [    1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [    1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [    1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [    1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [    1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [    1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [    1.246267] Call trace: [    1.248824]  nxp_fspi_exec_op+0xb04/0xb64 [    1.253031]  spi_mem_exec_op+0x3a0/0x430 [    1.257139]  spi_nor_read_id+0x80/0xcc [    1.261065]  spi_nor_scan+0x1ec/0xf10 [    1.264901]  spi_nor_probe+0x108/0x2fc [    1.268828]  spi_mem_probe+0x6c/0xbc [    1.272574]  spi_probe+0x84/0xe4 [    1.275958]  really_probe+0xbc/0x29c [    1.279713]  __driver_probe_device+0x78/0x12c [    1.284277]  driver_probe_device+0xd8/0x15c [    1.288660]  __device_attach_driver+0xb8/0x134 [    1.293316]  bus_for_each_drv+0x88/0xe8 [    1.297337]  __device_attach+0xa0/0x190 [    1.301353]  device_initial_probe+0x14/0x20 [    1.305734]  bus_probe_device+0xac/0xb0 [    1.309752]  device_add+0x5d0/0x790 [    1.313408]  __spi_add_device+0x134/0x204 [    1.317606]  of_register_spi_device+0x3b4/0x590 [    1.322348]  spi_register_controller+0x47c/0x754 [    1.327181]  devm_spi_register_controller+0x4c/0xa4 [    1.332289]  nxp_fspi_probe+0x1cc/0x2b0 [    1.336307]  platform_probe+0x68/0xc4 [    1.340145]  really_probe+0xbc/0x29c [    1.343893]  __driver_probe_device+0x78/0x12c [    1.348457]  driver_probe_device+0xd8/0x15c [    1.352838]  __driver_attach+0x90/0x19c [    1.356857]  bus_for_each_dev+0x7c/0xdc [    1.360877]  driver_attach+0x24/0x30 [    1.364624]  bus_add_driver+0xe4/0x208 [    1.368552]  driver_register+0x5c/0x124 [    1.372573]  __platform_driver_register+0x28/0x34 [    1.377497]  nxp_fspi_driver_init+0x1c/0x28 [    1.381888]  do_one_initcall+0x80/0x1c8 [    1.385908]  kernel_init_freeable+0x1c4/0x28c [    1.390472]  kernel_init+0x20/0x1d8 [    1.394138]  ret_from_fork+0x10/0x20 [    1.397885] ---[ end trace 0000000000000000 ]--- [    1.407908] ------------[ cut here ]------------(CVE-2024-53046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mptcp: init: protect sched with rcu_read_lock  Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created:    =============================   WARNING: suspicious RCU usage   6.12.0-rc2+ #11 Not tainted   -----------------------------   net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!    other info that might help us debug this:    rcu_scheduler_active = 2, debug_locks = 1   no locks held by mptcp_connect/176.    stack backtrace:   CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11   Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011   Call Trace:    \u0026lt;TASK\u0026gt;    dump_stack_lvl (lib/dump_stack.c:123)    lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)    mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7))    mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1))    ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28)    inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386)    ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1))    __sock_create (net/socket.c:1576)    __sys_socket (net/socket.c:1671)    ? __pfx___sys_socket (net/socket.c:1712)    ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1))    __x64_sys_socket (net/socket.c:1728)    do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1))    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)  That\u0026apos;s because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.(CVE-2024-53047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring/rw: fix missing NOWAIT check for O_DIRECT start write  When io_uring starts a write, it\u0026apos;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:  task:fio             state:D stack:0     pid:886   tgid:886   ppid:876 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_rwsem_wait+0x1e8/0x3f8  __percpu_down_read+0xe8/0x500  io_write+0xbb8/0xff8  io_issue_sqe+0x10c/0x1020  io_submit_sqes+0x614/0x2110  __arm64_sys_io_uring_enter+0x524/0x1038  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds.       Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963  with the attempting freezer stuck trying to grab the rwsem:  task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_down_write+0x2b0/0x680  freeze_super+0x248/0x8a8  do_vfs_ioctl+0x149c/0x1b18  __arm64_sys_ioctl+0xd0/0x1a0  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170  Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn\u0026apos;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.  Since freezing requires CAP_SYS_ADMIN in the first place, this isn\u0026apos;t something that can be triggered by a regular user.(CVE-2024-53052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: fix 6 GHz scan construction  If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that\u0026apos;s bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope.  Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it\u0026apos;s more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.(CVE-2024-53055)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: s5p-jpeg: prevent buffer overflows  The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it.  While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: dvbdev: prevent the risk of out of memory access  The dvbdev contains a static variable used to store dvb minors.  The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won\u0026apos;t check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it.  On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks.  This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity.  So, add explicit guards to prevent potential risk of OOM issues.(CVE-2024-53063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfs: Fix KMSAN warning in decode_getfattr_attrs()  Fix the following KMSAN warning:  CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_generic+0x806/0xb00  nfs4_xdr_dec_getattr+0x1de/0x240  rpcauth_unwrap_resp_decode+0xab/0x100  rpcauth_unwrap_resp+0x95/0xc0  call_decode+0x4ff/0xb50  __rpc_execute+0x57b/0x19d0  rpc_execute+0x368/0x5e0  rpc_run_task+0xcfe/0xee0  nfs4_proc_getattr+0x5b5/0x990  __nfs_revalidate_inode+0x477/0xd00  nfs_access_get_cached+0x1021/0x1cc0  nfs_do_access+0x9f/0xae0  nfs_permission+0x1e4/0x8c0  inode_permission+0x356/0x6c0  link_path_walk+0x958/0x1330  path_lookupat+0xce/0x6b0  filename_lookup+0x23e/0x770  vfs_statx+0xe7/0x970  vfs_fstatat+0x1f2/0x2c0  __se_sys_newfstatat+0x67/0x880  __x64_sys_newfstatat+0xbd/0x120  x64_sys_call+0x1826/0x3cf0  do_syscall_64+0xd0/0x1b0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized.  Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()  If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks.  Fix it by checking if i \u0026gt;= 0.(CVE-2024-53076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier  If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.(CVE-2024-53083)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tpm: Lock TPM chip in tpm_pm_suspend() first  Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour.  Aadress this by locking the TPM chip before checking any chip-\u0026gt;flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.(CVE-2024-53085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Mark hrtimer to expire in hard interrupt context  Like commit 2c0d278f3293f (\u0026quot;KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\u0026quot;) and commit 9090825fa9974 (\u0026quot;KVM: arm/arm64: Let the timer expire in hardirq context on RT\u0026quot;), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT.  The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT.  This fix a \u0026quot;scheduling while atomic\u0026quot; bug for PREEMPT_RT enabled kernels:   BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002  Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns  CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G        W          6.12.0-rc2+ #1774  Tainted: [W]=WARN  Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022  Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000          90000001167475a0 0000000000000000 90000001167475a8 9000000005644830          90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001          0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140          00000000000003fe 0000000000000001 000000000000000d 0000000000000003          0000000000000030 00000000000003f3 000000000790c000 9000000116747830          90000000057ef000 0000000000000000 9000000005644830 0000000000000004          0000000000000000 90000000057f4b58 0000000000000001 9000000116747868          900000000451b600 9000000005644830 9000000003a13998 0000000010000020          00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d          ...  Call Trace:  [\u0026lt;9000000003a13998\u0026gt;] show_stack+0x38/0x180  [\u0026lt;9000000004e3ea34\u0026gt;] dump_stack_lvl+0x84/0xc0  [\u0026lt;9000000003a71708\u0026gt;] __schedule_bug+0x48/0x60  [\u0026lt;9000000004e45734\u0026gt;] __schedule+0x1114/0x1660  [\u0026lt;9000000004e46040\u0026gt;] schedule_rtlock+0x20/0x60  [\u0026lt;9000000004e4e330\u0026gt;] rtlock_slowlock_locked+0x3f0/0x10a0  [\u0026lt;9000000004e4f038\u0026gt;] rt_spin_lock+0x58/0x80  [\u0026lt;9000000003b02d68\u0026gt;] hrtimer_cancel_wait_running+0x68/0xc0  [\u0026lt;9000000003b02e30\u0026gt;] hrtimer_cancel+0x70/0x80  [\u0026lt;ffff80000235eb70\u0026gt;] kvm_restore_timer+0x50/0x1a0 [kvm]  [\u0026lt;ffff8000023616c8\u0026gt;] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]  [\u0026lt;ffff80000234c2d4\u0026gt;] kvm_sched_in+0x34/0x60 [kvm]  [\u0026lt;9000000003a749a0\u0026gt;] finish_task_switch.isra.0+0x140/0x2e0  [\u0026lt;9000000004e44a70\u0026gt;] __schedule+0x450/0x1660  [\u0026lt;9000000004e45cb0\u0026gt;] schedule+0x30/0x180  [\u0026lt;ffff800002354c70\u0026gt;] kvm_vcpu_block+0x70/0x120 [kvm]  [\u0026lt;ffff800002354d80\u0026gt;] kvm_vcpu_halt+0x60/0x3e0 [kvm]  [\u0026lt;ffff80000235b194\u0026gt;] kvm_handle_gspr+0x3f4/0x4e0 [kvm]  [\u0026lt;ffff80000235f548\u0026gt;] kvm_handle_exit+0x1c8/0x260 [kvm](CVE-2024-53089)",
  "id": "OESA-2024-2492",
  "modified": "2026-08-06T11:07:58Z",
  "published": "2024-11-29T11:07:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2492"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45010"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46765"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47678"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47712"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49856"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49885"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49914"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50024"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50031"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50039"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50141"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50148"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50157"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50162"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50166"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50169"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50170"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50171"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50182"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50191"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50203"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50208"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50209"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50216"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50217"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50223"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50236"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50255"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50258"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50262"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50272"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50275"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50276"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50283"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50294"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50298"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50299"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53043"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53046"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53055"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53083"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53089"
    }
  ],
  "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-2023-52920",
    "CVE-2024-45010",
    "CVE-2024-46698",
    "CVE-2024-46713",
    "CVE-2024-46765",
    "CVE-2024-47678",
    "CVE-2024-47707",
    "CVE-2024-47712",
    "CVE-2024-47745",
    "CVE-2024-47747",
    "CVE-2024-47749",
    "CVE-2024-49856",
    "CVE-2024-49885",
    "CVE-2024-49899",
    "CVE-2024-49914",
    "CVE-2024-49915",
    "CVE-2024-50024",
    "CVE-2024-50031",
    "CVE-2024-50038",
    "CVE-2024-50039",
    "CVE-2024-50045",
    "CVE-2024-50062",
    "CVE-2024-50085",
    "CVE-2024-50093",
    "CVE-2024-50098",
    "CVE-2024-50141",
    "CVE-2024-50143",
    "CVE-2024-50148",
    "CVE-2024-50154",
    "CVE-2024-50157",
    "CVE-2024-50162",
    "CVE-2024-50166",
    "CVE-2024-50169",
    "CVE-2024-50170",
    "CVE-2024-50171",
    "CVE-2024-50182",
    "CVE-2024-50191",
    "CVE-2024-50192",
    "CVE-2024-50195",
    "CVE-2024-50203",
    "CVE-2024-50205",
    "CVE-2024-50208",
    "CVE-2024-50209",
    "CVE-2024-50216",
    "CVE-2024-50217",
    "CVE-2024-50223",
    "CVE-2024-50230",
    "CVE-2024-50234",
    "CVE-2024-50236",
    "CVE-2024-50241",
    "CVE-2024-50248",
    "CVE-2024-50255",
    "CVE-2024-50258",
    "CVE-2024-50262",
    "CVE-2024-50265",
    "CVE-2024-50269",
    "CVE-2024-50271",
    "CVE-2024-50272",
    "CVE-2024-50273",
    "CVE-2024-50275",
    "CVE-2024-50276",
    "CVE-2024-50283",
    "CVE-2024-50284",
    "CVE-2024-50289",
    "CVE-2024-50294",
    "CVE-2024-50298",
    "CVE-2024-50299",
    "CVE-2024-53043",
    "CVE-2024-53046",
    "CVE-2024-53047",
    "CVE-2024-53052",
    "CVE-2024-53055",
    "CVE-2024-53061",
    "CVE-2024-53063",
    "CVE-2024-53066",
    "CVE-2024-53076",
    "CVE-2024-53083",
    "CVE-2024-53085",
    "CVE-2024-53089"
  ]
}