{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-234.0.0.136.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-234.0.0.136.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n      fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n      9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n  $ lspci\n  ...\n  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n  ...\n  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n  10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: mt7621: Add sentinel to quirks table  Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call.  This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in:  commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;)  Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  memcg: fix possible use-after-free in memcg_write_event_control()  memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call.  As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file.  Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too.  Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses.  The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through.  With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s.  Fix the bug by resurrecting the file type check in __file_cft().  Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection.  Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfc: nci: fix possible NULL pointer dereference in send_acknowledge()  Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[   31.077578] ------------[ cut here ]------------\n[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.077953] Modules linked in:\n[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[   31.078102] Hardware name: xlnx,zynqmp (DT)\n[   31.078169] Workqueue: events_unbound deferred_probe_work_func\n[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[   31.078550] sp : ffffffc083bb2e10\n[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[   31.080307] Call trace:\n[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120\n[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac\n[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684\n[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0\n[   31.081139]  commit_tail+0x234/0x294\n[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210\n[   31.081363]  drm_atomic_commit+0x100/0x140\n[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384\n[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c\n[   31.081725]  drm_client_modeset_commit+0x34/0x5c\n[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[   31.081899]  drm_fb_helper_set_par+0x50/0x70\n[   31.081971]  fbcon_init+0x538/0xc48\n[   31.082047]  visual_init+0x16c/0x23c\n[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634\n[   31.082320]  do_take_over_console+0x24c/0x33c\n[   31.082429]  do_fbcon_takeover+0xbc/0x1b0\n[   31.082503]  fbcon_fb_registered+0x2d0/0x34c\n[   31.082663]  register_framebuffer+0x27c/0x38c\n[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[   31.082939]  drm_fb_helper_initial_config+0x50/0x74\n[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108\n[   31.083115]  drm_client_register+0xa0/0xf4\n[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc\n[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0\n[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0\n[   31.083616]  platform_probe+0x8c/0x13c\n[   31.083713]  really_probe+0x258/0x59c\n[   31.083793]  __driver_probe_device+0xc4/0x224\n[   31.083878]  driver_probe_device+0x70/0x1c0\n[   31.083961]  __device_attach_driver+0x108/0x1e0\n[   31.084052]  bus_for_each_drv+0x9c/0x100\n[   31.084125]  __device_attach+0x100/0x298\n[   31.084207]  device_initial_probe+0x14/0x20\n[   31.084292]  bus_probe_device+0xd8/0xdc\n[   31.084368]  deferred_probe_work_func+0x11c/0x180\n[   31.084451]  process_one_work+0x3ac/0x988\n[   31.084643]  worker_thread+0x398/0x694\n[   31.084752]  kthread+0x1bc/0x1c0\n[   31.084848]  ret_from_fork+0x10/0x20\n[   31.084932] irq event stamp: 64549\n[   31.084970] hardirqs last  enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[   31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n  rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n  __do_softirq kernel/softirq.c:588 [inline]\n  invoke_softirq kernel/softirq.c:428 [inline]\n  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n       CPU0                CPU1\n       ----                ----\n  kswapd\n   balance_pgdat\n    lock(fs_reclaim)\n                      exfat_iterate\n                       lock(\u0026amp;sbi-\u0026gt;s_lock)\n                       exfat_readdir\n                        exfat_get_uniname_from_ext_entry\n                         exfat_get_dentry_set\n                          __exfat_get_dentry_set\n                           kmalloc_array\n                            ...\n                            lock(fs_reclaim)\n    ...\n    evict\n     exfat_evict_inode\n      lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only decrement add_addr_accepted for MPJ req\r\n\r\nAdding the following warning ...\r\n\r\n  WARN_ON_ONCE(msk-\u0026gt;pm.add_addr_accepted == 0)\r\n\r\n... before decrementing the add_addr_accepted counter helped to find a\nbug when running the \u0026quot;remove single subflow\u0026quot; subtest from the\nmptcp_join.sh selftest.\r\n\r\nRemoving a \u0026apos;subflow\u0026apos; endpoint will first trigger a RM_ADDR, then the\nsubflow closure. Before this patch, and upon the reception of the\nRM_ADDR, the other peer will then try to decrement this\nadd_addr_accepted. That\u0026apos;s not correct because the attached subflows have\nnot been created upon the reception of an ADD_ADDR.\r\n\r\nA way to solve that is to decrement the counter only if the attached\nsubflow was an MP_JOIN to a remote id that was not 0, and initiated by\nthe host receiving the RM_ADDR.(CVE-2024-45009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n        1. In dwc3_gadget_suspend, there is a chance of a timeout when\n        moving the USB core to the halt state after clearing the\n        run/stop bit by software.\n        2. In dwc3_core_exit, the event buffer is cleared regardless of\n        the USB core\u0026apos;s status, which may lead to an SMMU faults and\n        other memory issues. if the USB core tries to access the event\n        buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software  when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU.  I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems.  Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n  #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x7f/0x90\n  lockdep_rcu_suspicious+0x13f/0x1a0\n  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n  kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n  vmx_leave_nested+0x30/0x40 [kvm_intel]\n  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n  ? mark_held_locks+0x49/0x70\n  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  ? lock_acquire+0xba/0x2d0\n  ? find_held_lock+0x2b/0x80\n  ? do_user_addr_fault+0x40c/0x6f0\n  ? lock_release+0xb7/0x270\n  __x64_sys_ioctl+0x82/0xb0\n  do_syscall_64+0x6c/0x170\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n  \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[   36.926103] ==================================================================\n[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[   36.946721]\n[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[   36.961260] Call trace:\n[   36.963723]  dump_backtrace+0x90/0xe8\n[   36.967414]  show_stack+0x18/0x24\n[   36.970749]  dump_stack_lvl+0x78/0x90\n[   36.974451]  print_report+0x114/0x5cc\n[   36.978151]  kasan_report+0xa4/0xf0\n[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28\n[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838\n[   36.990800]  spi_mem_exec_op+0x8ec/0xd30\n[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0\n[   36.999323]  spi_mem_dirmap_write+0x238/0x32c\n[   37.003710]  spi_nor_write_data+0x220/0x374\n[   37.007932]  spi_nor_write+0x110/0x2e8\n[   37.011711]  mtd_write_oob_std+0x154/0x1f0\n[   37.015838]  mtd_write_oob+0x104/0x1d0\n[   37.019617]  mtd_write+0xb8/0x12c\n[   37.022953]  mtdchar_write+0x224/0x47c\n[   37.026732]  vfs_write+0x1e4/0x8c8\n[   37.030163]  ksys_write+0xec/0x1d0\n[   37.033586]  __arm64_sys_write+0x6c/0x9c\n[   37.037539]  invoke_syscall+0x6c/0x258\n[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.046244]  do_el0_svc+0x44/0x5c\n[   37.049589]  el0_svc+0x38/0x78\n[   37.052681]  el0t_64_sync_handler+0x13c/0x158\n[   37.057077]  el0t_64_sync+0x190/0x194\n[   37.060775]\n[   37.062274] Allocated by task 455:\n[   37.065701]  kasan_save_stack+0x2c/0x54\n[   37.069570]  kasan_save_track+0x20/0x3c\n[   37.073438]  kasan_save_alloc_info+0x40/0x54\n[   37.077736]  __kasan_kmalloc+0xa0/0xb8\n[   37.081515]  __kmalloc_noprof+0x158/0x2f8\n[   37.085563]  mtd_kmalloc_up_to+0x120/0x154\n[   37.089690]  mtdchar_write+0x130/0x47c\n[   37.093469]  vfs_write+0x1e4/0x8c8\n[   37.096901]  ksys_write+0xec/0x1d0\n[   37.100332]  __arm64_sys_write+0x6c/0x9c\n[   37.104287]  invoke_syscall+0x6c/0x258\n[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.112972]  do_el0_svc+0x44/0x5c\n[   37.116319]  el0_svc+0x38/0x78\n[   37.119401]  el0t_64_sync_handler+0x13c/0x158\n[   37.123788]  el0t_64_sync+0x190/0x194\n[   37.127474]\n[   37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[   37.128977]  which belongs to the cache kmalloc-8 of size 8\n[   37.141177] The buggy address is located 0 bytes inside of\n[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[   37.153465]\n[   37.154971] The buggy address belongs to the physical page:\n[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[   37.175149] page_type: 0xfdffffff(slab)\n[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[   37.194553] page dumped because: kasan: bad access detected\n[   37.200144]\n[   37.201647] Memory state around the buggy address:\n[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[   37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[   37.228186]                                ^\n[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num.  This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst;     378         struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-\u0026gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         \u0026amp;stream-\u0026gt;out_transfer_func,     393                                         \u0026amp;mpc-\u0026gt;blender_params, false))     394                                 params = \u0026amp;mpc-\u0026gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --\u0026gt; 401         mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled  Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.  This was discovered through the lock debugging, and the corresponding log is as follows:  raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace:  warn_bogus_irq_restore+0x30/0x40  _raw_spin_unlock_irqrestore+0x84/0xc8  add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]  hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]  hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]  create_qp+0x138/0x258  ib_create_qp_kernel+0x50/0xe8  create_mad_qp+0xa8/0x128  ib_mad_port_open+0x218/0x448  ib_mad_init_device+0x70/0x1f8  add_client_context+0xfc/0x220  enable_device_and_get+0xd0/0x140  ib_register_device.part.0+0xf4/0x1c8  ib_register_device+0x34/0x50  hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]  hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]  hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt; ```  After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0x169/0x550 mm/kasan/report.c:488    kasan_report+0x143/0x180 mm/kasan/report.c:601    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    \u0026lt;/TASK\u0026gt;    Allocated by task 2:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    unpoison_slab_object mm/kasan/common.c:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579    poison_slab_object mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    \u0026lt;TASK\u0026gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    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  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize get_bytes_per_element\u0026apos;s default to 1  Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y \u0026amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in degamma hardware format translation  Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-\u0026gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  Freed by task 5218:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2252 [inline]  slab_free mm/slub.c:4473 [inline]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  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  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error  In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:  ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace:  \u0026lt;TASK\u0026gt;  add_transaction_credits+0x5d1/0x5e0  start_this_handle+0x1ef/0x6a0  jbd2__journal_start+0x18b/0x340  ext4_dirty_inode+0x5d/0xb0  __mark_inode_dirty+0xe4/0x5d0  generic_update_time+0x60/0x70 [...] ============================================  So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.  Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  \u0026lt;IRQ\u0026gt; kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  \u0026lt;/IRQ\u0026gt;  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)",
  "id": "OESA-2024-2322",
  "modified": "2026-08-06T11:07:48Z",
  "published": "2024-11-01T11:07:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48916"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35878"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35990"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36286"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38635"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42315"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45009"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49892"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48916",
    "CVE-2022-48952",
    "CVE-2022-48988",
    "CVE-2023-52917",
    "CVE-2023-52918",
    "CVE-2023-52919",
    "CVE-2024-35878",
    "CVE-2024-35990",
    "CVE-2024-36286",
    "CVE-2024-38635",
    "CVE-2024-38667",
    "CVE-2024-42152",
    "CVE-2024-42301",
    "CVE-2024-42315",
    "CVE-2024-43841",
    "CVE-2024-43858",
    "CVE-2024-43867",
    "CVE-2024-43871",
    "CVE-2024-43894",
    "CVE-2024-45009",
    "CVE-2024-46675",
    "CVE-2024-46689",
    "CVE-2024-46722",
    "CVE-2024-46724",
    "CVE-2024-46757",
    "CVE-2024-46802",
    "CVE-2024-46830",
    "CVE-2024-46853",
    "CVE-2024-47667",
    "CVE-2024-47669",
    "CVE-2024-47684",
    "CVE-2024-47685",
    "CVE-2024-47692",
    "CVE-2024-47695",
    "CVE-2024-47698",
    "CVE-2024-47709",
    "CVE-2024-47710",
    "CVE-2024-47720",
    "CVE-2024-47735",
    "CVE-2024-47737",
    "CVE-2024-47757",
    "CVE-2024-49866",
    "CVE-2024-49867",
    "CVE-2024-49868",
    "CVE-2024-49892",
    "CVE-2024-49894",
    "CVE-2024-49895",
    "CVE-2024-49900",
    "CVE-2024-49902",
    "CVE-2024-49903",
    "CVE-2024-49911",
    "CVE-2024-49927",
    "CVE-2024-49959",
    "CVE-2024-49965",
    "CVE-2024-49966",
    "CVE-2024-49969",
    "CVE-2024-49974",
    "CVE-2024-49985",
    "CVE-2024-50025",
    "CVE-2024-50036",
    "CVE-2024-50046",
    "CVE-2024-50049"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.103.0.184.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.103.0.184.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  xen-netfront: Fix NULL sring after live migration  A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM.  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace:  finish_task_switch+0x71/0x230  timerqueue_del+0x1d/0x40  hrtimer_try_to_cancel+0xb5/0x110  xennet_alloc_rx_buffers+0x2a0/0x2a0  napi_busy_loop+0xdb/0x270  sock_poll+0x87/0x90  do_sys_poll+0x26f/0x580  tracing_map_insert+0x1d4/0x2f0  event_hist_trigger+0x14a/0x260   finish_task_switch+0x71/0x230  __schedule+0x256/0x890  recalc_sigpending+0x1b/0x50  xen_sched_clock+0x15/0x20  __rb_reserve_next+0x12d/0x140  ring_buffer_lock_reserve+0x123/0x3d0  event_triggers_call+0x87/0xb0  trace_event_buffer_commit+0x1c4/0x210  xen_clocksource_get_cycles+0x15/0x20  ktime_get_ts64+0x51/0xf0  SyS_ppoll+0x160/0x1a0  SyS_ppoll+0x160/0x1a0  do_syscall_64+0x73/0x130  entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]---  xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed  There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time(CVE-2022-48969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: stop the device in bond_setup_by_slave()\r\n\r\nCommit 9eed321cde22 (\u0026quot;net: lapbether: only support ethernet devices\u0026quot;)\nhas been able to keep syzbot away from net/lapb, until today.\r\n\r\nIn the following splat [1], the issue is that a lapbether device has\nbeen created on a bonding device without members. Then adding a non\nARPHRD_ETHER member forced the bonding master to change its type.\r\n\r\nThe fix is to make sure we call dev_close() in bond_setup_by_slave()\nso that the potential linked lapbether devices (or any other devices\nhaving assumptions on the physical device) are removed.\r\n\r\nA similar bug has been addressed in commit 40baec225765\n(\u0026quot;bonding: fix panic on non-ARPHRD_ETHER enslave failure\u0026quot;)\r\n\r\n[1]\nskbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0\nkernel BUG at net/core/skbuff.c:192 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : skb_panic net/core/skbuff.c:188 [inline]\npc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nlr : skb_panic net/core/skbuff.c:188 [inline]\nlr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nsp : ffff800096a06aa0\nx29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000\nx26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea\nx23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140\nx20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100\nx17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001\nx14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00\nx8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c\nx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086\nCall trace:\nskb_panic net/core/skbuff.c:188 [inline]\nskb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nskb_push+0xf0/0x108 net/core/skbuff.c:2446\nip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384\ndev_hard_header include/linux/netdevice.h:3136 [inline]\nlapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257\nlapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447\nlapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149\nlapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251\n__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326\nlapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nlapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nbond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332\nbond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539\ndev_ifsioc+0x754/0x9ac\ndev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786\nsock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217\nsock_ioctl+0x4e8/0x834 net/socket.c:1322\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_\n---truncated---(CVE-2023-52784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n    netif_receive_skb_internal net/core/dev.c:5723 [inline]\n    netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix UAF in svc_tcp_listen_data_ready()\r\n\r\nAfter the listener svc_sock is freed, and before invoking svc_tcp_accept()\nfor the established child sock, there is a window that the newsock\nretaining a freed listener svc_sock in sk_user_data which cloning from\nparent. In the race window, if data is received on the newsock, we will\nobserve use-after-free report in svc_tcp_listen_data_ready().\r\n\r\nReproduce by two tasks:\r\n\r\n1. while :; do rpc.nfsd 0 ; rpc.nfsd; done\n2. while :; do echo \u0026quot;\u0026quot; | ncat -4 127.0.0.1 2049 ; done\r\n\r\nKASAN report:\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]\n  Read of size 8 at addr ffff888139d96228 by task nc/102553\n  CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18\n  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   dump_stack_lvl+0x33/0x50\n   print_address_description.constprop.0+0x27/0x310\n   print_report+0x3e/0x70\n   kasan_report+0xae/0xe0\n   svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]\n   tcp_data_queue+0x9f4/0x20e0\n   tcp_rcv_established+0x666/0x1f60\n   tcp_v4_do_rcv+0x51c/0x850\n   tcp_v4_rcv+0x23fc/0x2e80\n   ip_protocol_deliver_rcu+0x62/0x300\n   ip_local_deliver_finish+0x267/0x350\n   ip_local_deliver+0x18b/0x2d0\n   ip_rcv+0x2fb/0x370\n   __netif_receive_skb_one_core+0x166/0x1b0\n   process_backlog+0x24c/0x5e0\n   __napi_poll+0xa2/0x500\n   net_rx_action+0x854/0xc90\n   __do_softirq+0x1bb/0x5de\n   do_softirq+0xcb/0x100\n   \u0026lt;/IRQ\u0026gt;\n   \u0026lt;TASK\u0026gt;\n   ...\n   \u0026lt;/TASK\u0026gt;\r\n\r\n  Allocated by task 102371:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   __kasan_kmalloc+0x7b/0x90\n   svc_setup_socket+0x52/0x4f0 [sunrpc]\n   svc_addsock+0x20d/0x400 [sunrpc]\n   __write_ports_addfd+0x209/0x390 [nfsd]\n   write_ports+0x239/0x2c0 [nfsd]\n   nfsctl_transaction_write+0xac/0x110 [nfsd]\n   vfs_write+0x1c3/0xae0\n   ksys_write+0xed/0x1c0\n   do_syscall_64+0x38/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\n  Freed by task 102551:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   kasan_save_free_info+0x2a/0x50\n   __kasan_slab_free+0x106/0x190\n   __kmem_cache_free+0x133/0x270\n   svc_xprt_free+0x1e2/0x350 [sunrpc]\n   svc_xprt_destroy_all+0x25a/0x440 [sunrpc]\n   nfsd_put+0x125/0x240 [nfsd]\n   nfsd_svc+0x2cb/0x3c0 [nfsd]\n   write_threads+0x1ac/0x2a0 [nfsd]\n   nfsctl_transaction_write+0xac/0x110 [nfsd]\n   vfs_write+0x1c3/0xae0\n   ksys_write+0xed/0x1c0\n   do_syscall_64+0x38/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\nFix the UAF by simply doing nothing in svc_tcp_listen_data_ready()\nif state != TCP_LISTEN, that will avoid dereferencing svsk for all\nchild socket.(CVE-2023-52885)\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:  RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled  Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.  This was discovered through the lock debugging, and the corresponding log is as follows:  raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace:  warn_bogus_irq_restore+0x30/0x40  _raw_spin_unlock_irqrestore+0x84/0xc8  add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]  hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]  hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]  create_qp+0x138/0x258  ib_create_qp_kernel+0x50/0xe8  create_mad_qp+0xa8/0x128  ib_mad_port_open+0x218/0x448  ib_mad_init_device+0x70/0x1f8  add_client_context+0xfc/0x220  enable_device_and_get+0xd0/0x140  ib_register_device.part.0+0xf4/0x1c8  ib_register_device+0x34/0x50  hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]  hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]  hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\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:  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:  wifi: iwlwifi: mvm: avoid NULL pointer dereference  iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: prevent nf_skb_duplicated corruption  syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1].  Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well.  [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316  caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace:  \u0026lt;TASK\u0026gt;   __dump_stack lib/dump_stack.c:93 [inline]   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119   check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49   nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87   nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook+0x2c4/0x450 include/linux/netfilter.h:269   NF_HOOK_COND include/linux/netfilter.h:302 [inline]   ip_output+0x185/0x230 net/ipv4/ip_output.c:433   ip_local_out net/ipv4/ip_output.c:129 [inline]   ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495   udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981   udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269   sock_sendmsg_nosec net/socket.c:730 [inline]   __sock_sendmsg+0x1a6/0x270 net/socket.c:745   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597   ___sys_sendmsg net/socket.c:2651 [inline]   __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737   __do_sys_sendmmsg net/socket.c:2766 [inline]   __se_sys_sendmmsg net/socket.c:2763 [inline]   __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763   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:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68  \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\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:  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:  tty: n_gsm: Fix use-after-free in gsm_cleanup_mux  BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace:  \u0026lt;TASK\u0026gt;  gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]  __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389  update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500  __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846  __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107  __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]  ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195  ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79  __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338  __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  Allocated by task 65:  gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]  gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]  gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]  gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]  tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391  tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39  flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445  process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229  worker_thread+0x3dc/0x950 kernel/workqueue.c:3391  kthread+0x2a3/0x370 kernel/kthread.c:389  ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257  Freed by task 3367:  kfree+0x126/0x420 mm/slub.c:4580  gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  unicode: Don\u0026apos;t special case ignorable code points  We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\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\n(CVE-2024-50151)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ceph: remove the incorrect Fw reference check when dirtying pages  When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: sisfb: Fix strbuf array overflow  The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\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:  nilfs2: propagate directory read errors from nilfs_find_entry()  Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2.  The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails.  If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts.  Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry().  The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\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:  nilfs2: fix potential deadlock with newly created symlinks  Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.  This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().  This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called.  However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL.  Then, memory allocation called from page_symlink() etc.  triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held:  Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\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:  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:  fs/ntfs3: Additional check in ni_clear()  Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)\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:  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:  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:  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:  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:  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:  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)",
  "id": "OESA-2024-2491",
  "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-2491"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52784"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52885"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
    },
    {
      "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-49899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50038"
    },
    {
      "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-50073"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50151"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
    },
    {
      "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-50273"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
    }
  ],
  "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-2022-48969",
    "CVE-2023-52784",
    "CVE-2023-52843",
    "CVE-2023-52885",
    "CVE-2024-46713",
    "CVE-2024-47735",
    "CVE-2024-47745",
    "CVE-2024-47747",
    "CVE-2024-47749",
    "CVE-2024-49899",
    "CVE-2024-49929",
    "CVE-2024-49952",
    "CVE-2024-50038",
    "CVE-2024-50045",
    "CVE-2024-50062",
    "CVE-2024-50073",
    "CVE-2024-50089",
    "CVE-2024-50143",
    "CVE-2024-50151",
    "CVE-2024-50179",
    "CVE-2024-50180",
    "CVE-2024-50192",
    "CVE-2024-50202",
    "CVE-2024-50205",
    "CVE-2024-50229",
    "CVE-2024-50230",
    "CVE-2024-50241",
    "CVE-2024-50244",
    "CVE-2024-50248",
    "CVE-2024-50262",
    "CVE-2024-50265",
    "CVE-2024-50269",
    "CVE-2024-50273",
    "CVE-2024-50289",
    "CVE-2024-53052",
    "CVE-2024-53061",
    "CVE-2024-53066"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "perf-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-76.0.0.69.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "perf-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-76.0.0.69.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-76.0.0.69.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\n\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-iocost: avoid out of bounds shift\n\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\n\n[  186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\n\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\n\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/tsens: Fix null pointer dereference\n\ncompute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)\nas compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null\npointer dereference (if DEBUG or DYNAMIC_DEBUG set).\nFix this bug by adding null pointer check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: pcie: handle randbuf allocation failure\n\nThe kzalloc() in brcmf_pcie_download_fw_nvram() will return null\nif the physical memory has run out. As a result, if we use\nget_random_bytes() to generate random bytes in the randbuf, the\nnull pointer dereference bug will happen.\n\nIn order to prevent allocation failure, this patch adds a separate\nfunction using buffer on kernel stack to generate random bytes in\nthe randbuf, which could prevent the kernel stack from overflow.(CVE-2024-38575)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntools/nolibc/stdlib: fix memory error in realloc()\n\nPass user_p_len to memcpy() instead of heap-\u0026gt;len to prevent realloc()\nfrom copying an extra sizeof(heap) bytes from beyond the allocated\nregion.(CVE-2024-38585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\n\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\n\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\n\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL\n\ncommit a421ef303008 (\u0026quot;mm: allow !GFP_KERNEL allocations for kvmalloc\u0026quot;)\nincludes support for __GFP_NOFAIL, but it presents a conflict with commit\ndd544141b9eb (\u0026quot;vmalloc: back off when the current task is OOM-killed\u0026quot;).  A\npossible scenario is as follows:\n\nprocess-a\n__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)\n    __vmalloc_area_node()\n        vm_area_alloc_pages()\n\t\t--\u0026gt; oom-killer send SIGKILL to process-a\n        if (fatal_signal_pending(current)) break;\n--\u0026gt; return NULL;\n\nTo fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()\nif __GFP_NOFAIL set.\n\nThis issue occurred during OPLUS KASAN TEST. Below is part of the log\n-\u0026gt; oom-killer sends signal to process\n[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198\n\n[65731.259685] [T32454] Call trace:\n[65731.259698] [T32454]  dump_backtrace+0xf4/0x118\n[65731.259734] [T32454]  show_stack+0x18/0x24\n[65731.259756] [T32454]  dump_stack_lvl+0x60/0x7c\n[65731.259781] [T32454]  dump_stack+0x18/0x38\n[65731.259800] [T32454]  mrdump_common_die+0x250/0x39c [mrdump]\n[65731.259936] [T32454]  ipanic_die+0x20/0x34 [mrdump]\n[65731.260019] [T32454]  atomic_notifier_call_chain+0xb4/0xfc\n[65731.260047] [T32454]  notify_die+0x114/0x198\n[65731.260073] [T32454]  die+0xf4/0x5b4\n[65731.260098] [T32454]  die_kernel_fault+0x80/0x98\n[65731.260124] [T32454]  __do_kernel_fault+0x160/0x2a8\n[65731.260146] [T32454]  do_bad_area+0x68/0x148\n[65731.260174] [T32454]  do_mem_abort+0x151c/0x1b34\n[65731.260204] [T32454]  el1_abort+0x3c/0x5c\n[65731.260227] [T32454]  el1h_64_sync_handler+0x54/0x90\n[65731.260248] [T32454]  el1h_64_sync+0x68/0x6c\n\n[65731.260269] [T32454]  z_erofs_decompress_queue+0x7f0/0x2258\n--\u0026gt; be-\u0026gt;decompressed_pages = kvcalloc(be-\u0026gt;nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);\n\tkernel panic by NULL pointer dereference.\n\terofs assume kvmalloc with __GFP_NOFAIL never return NULL.\n[65731.260293] [T32454]  z_erofs_runqueue+0xf30/0x104c\n[65731.260314] [T32454]  z_erofs_readahead+0x4f0/0x968\n[65731.260339] [T32454]  read_pages+0x170/0xadc\n[65731.260364] [T32454]  page_cache_ra_unbounded+0x874/0xf30\n[65731.260388] [T32454]  page_cache_ra_order+0x24c/0x714\n[65731.260411] [T32454]  filemap_fault+0xbf0/0x1a74\n[65731.260437] [T32454]  __do_fault+0xd0/0x33c\n[65731.260462] [T32454]  handle_mm_fault+0xf74/0x3fe0\n[65731.260486] [T32454]  do_mem_abort+0x54c/0x1b34\n[65731.260509] [T32454]  el0_da+0x44/0x94\n[65731.260531] [T32454]  el0t_64_sync_handler+0x98/0xb4\n[65731.260553] [T32454]  el0t_64_sync+0x198/0x19c(CVE-2024-39474)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix variable length array abuse in btree_iter\n\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\n\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: Fix use-after-free bug in gb_interface_release due to race condition.\n\nIn gb_interface_create, \u0026amp;intf-\u0026gt;mode_switch_completion is bound with\ngb_interface_mode_switch_work. Then it will be started by\ngb_interface_request_mode_switch. Here is the relevant code.\nif (!queue_work(system_long_wq, \u0026amp;intf-\u0026gt;mode_switch_work)) {\n\t...\n}\n\nIf we call gb_interface_release to make cleanup, there may be an\nunfinished work. This function will call kfree to free the object\n\u0026quot;intf\u0026quot;. However, if gb_interface_mode_switch_work is scheduled to\nrun after kfree, it may cause use-after-free error as\ngb_interface_mode_switch_work will use the object \u0026quot;intf\u0026quot;.\nThe possible execution flow that may lead to the issue is as follows:\n\nCPU0                            CPU1\n\n                            |   gb_interface_create\n                            |   gb_interface_request_mode_switch\ngb_interface_release        |\nkfree(intf) (free)          |\n                            |   gb_interface_mode_switch_work\n                            |   mutex_lock(\u0026amp;intf-\u0026gt;mutex) (use)\n\nFix it by canceling the work before kfree.(CVE-2024-39495)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/dpt: Make DPT object unshrinkable\n\nIn some scenarios, the DPT object gets shrunk but\nthe actual framebuffer did not and thus its still\nthere on the DPT\u0026apos;s vm-\u0026gt;bound_list. Then it tries to\nrewrite the PTEs via a stale CPU mapping. This causes panic.\n\n[vsyrjala: Add TODO comment]\n(cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)(CVE-2024-40924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: Clear napi-\u0026gt;skb before dev_kfree_skb_any()\n\ngve_rx_free_skb incorrectly leaves napi-\u0026gt;skb referencing an skb after it\nis freed with dev_kfree_skb_any(). This can result in a subsequent call\nto napi_get_frags returning a dangling pointer.\n\nFix this by clearing napi-\u0026gt;skb before the skb is freed.(CVE-2024-40937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: shmem: fix getting incorrect lruvec when replacing a shmem folio\n\nWhen testing shmem swapin, I encountered the warning below on my machine. \nThe reason is that replacing an old shmem folio with a new one causes\nmem_cgroup_migrate() to clear the old folio\u0026apos;s memcg data.  As a result,\nthe old folio cannot get the correct memcg\u0026apos;s lruvec needed to remove\nitself from the LRU list when it is being freed.  This could lead to\npossible serious problems, such as LRU list crashes due to holding the\nwrong LRU lock, and incorrect LRU statistics.\n\nTo fix this issue, we can fallback to use the mem_cgroup_replace_folio()\nto replace the old shmem folio.\n\n[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960\n[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)\n[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000\n[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n[ 5241.100338] ------------[ cut here ]------------\n[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150\n[...]\n[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150\n[ 5241.100376] sp : ffff80008b38b930\n[...]\n[ 5241.100398] Call trace:\n[ 5241.100399]  folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100401]  __page_cache_release+0x90/0x300\n[ 5241.100404]  __folio_put+0x50/0x108\n[ 5241.100406]  shmem_replace_folio+0x1b4/0x240\n[ 5241.100409]  shmem_swapin_folio+0x314/0x528\n[ 5241.100411]  shmem_get_folio_gfp+0x3b4/0x930\n[ 5241.100412]  shmem_fault+0x74/0x160\n[ 5241.100414]  __do_fault+0x40/0x218\n[ 5241.100417]  do_shared_fault+0x34/0x1b0\n[ 5241.100419]  do_fault+0x40/0x168\n[ 5241.100420]  handle_pte_fault+0x80/0x228\n[ 5241.100422]  __handle_mm_fault+0x1c4/0x440\n[ 5241.100424]  handle_mm_fault+0x60/0x1f0\n[ 5241.100426]  do_page_fault+0x120/0x488\n[ 5241.100429]  do_translation_fault+0x4c/0x68\n[ 5241.100431]  do_mem_abort+0x48/0xa0\n[ 5241.100434]  el0_da+0x38/0xc0\n[ 5241.100436]  el0t_64_sync_handler+0x68/0xc0\n[ 5241.100437]  el0t_64_sync+0x14c/0x150\n[ 5241.100439] ---[ end trace 0000000000000000 ]---\n\n[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]\n  Link: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba.com(CVE-2024-40949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL deref in fib6_nh_init()\n\nsyzbot reminds us that in6_dev_get() can return NULL.\n\nfib6_nh_init()\n    ip6_validate_gw(  \u0026amp;idev  )\n        ip6_route_check_nh(  idev  )\n            *idev = in6_dev_get(dev); // can be NULL\n\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606\nCode: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b\nRSP: 0018:ffffc900032775a0 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8\nRBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000\nR10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8\nR13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000\nFS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809\n  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853\n  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483\n  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579\n  sock_do_ioctl+0x158/0x460 net/socket.c:1222\n  sock_ioctl+0x629/0x8e0 net/socket.c:1341\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:907 [inline]\n  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f940f07cea9(CVE-2024-40961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Disassociate vcpus from redistributor region on teardown\n\nWhen tearing down a redistributor region, make sure we don\u0026apos;t have\nany dangling pointer to that region stored in a vcpu.(CVE-2024-40989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/sqpoll: work around a potential audit memory leak\n\nkmemleak complains that there\u0026apos;s a memory leak related to connect\nhandling:\n\nunreferenced object 0xffff0001093bdf00 (size 128):\ncomm \u0026quot;iou-sqp-455\u0026quot;, pid 457, jiffies 4294894164\nhex dump (first 32 bytes):\n02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00  ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nbacktrace (crc 2e481b1a):\n[\u0026lt;00000000c0a26af4\u0026gt;] kmemleak_alloc+0x30/0x38\n[\u0026lt;000000009c30bb45\u0026gt;] kmalloc_trace+0x228/0x358\n[\u0026lt;000000009da9d39f\u0026gt;] __audit_sockaddr+0xd0/0x138\n[\u0026lt;0000000089a93e34\u0026gt;] move_addr_to_kernel+0x1a0/0x1f8\n[\u0026lt;000000000b4e80e6\u0026gt;] io_connect_prep+0x1ec/0x2d4\n[\u0026lt;00000000abfbcd99\u0026gt;] io_submit_sqes+0x588/0x1e48\n[\u0026lt;00000000e7c25e07\u0026gt;] io_sq_thread+0x8a4/0x10e4\n[\u0026lt;00000000d999b491\u0026gt;] ret_from_fork+0x10/0x20\n\nwhich can can happen if:\n\n1) The command type does something on the prep side that triggers an\n   audit call.\n2) The thread hasn\u0026apos;t done any operations before this that triggered\n   an audit call inside -\u0026gt;issue(), where we have audit_uring_entry()\n   and audit_uring_exit().\n\nWork around this by issuing a blanket NOP operation before the SQPOLL\ndoes anything.(CVE-2024-41001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: check if a hash-index is in cpu_possible_mask\n\nThe problem is that there are systems where cpu_possible_mask has gaps\nbetween set CPUs, for example SPARC.  In this scenario addr_to_vb_xa()\nhash function can return an index which accesses to not-possible and not\nsetup CPU area using per_cpu() macro.  This results in an oops on SPARC.\n\nA per-cpu vmap_block_queue is also used as hash table, incorrectly\nassuming the cpu_possible_mask has no gaps.  Fix it by adjusting an index\nto a next possible CPU.(CVE-2024-41032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()\n\nThe following is emitted when using idxd (DSA) dmanegine as the data\nmover for ntb_transport that ntb_netdev uses.\n\n[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526\n[74412.556784] caller is netif_rx_internal+0x42/0x130\n[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5\n[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024\n[74412.581699] Call Trace:\n[74412.584514]  \u0026lt;TASK\u0026gt;\n[74412.586933]  dump_stack_lvl+0x55/0x70\n[74412.591129]  check_preemption_disabled+0xc8/0xf0\n[74412.596374]  netif_rx_internal+0x42/0x130\n[74412.600957]  __netif_rx+0x20/0xd0\n[74412.604743]  ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]\n[74412.610985]  ntb_complete_rxc+0xed/0x140 [ntb_transport]\n[74412.617010]  ntb_rx_copy_callback+0x53/0x80 [ntb_transport]\n[74412.623332]  idxd_dma_complete_txd+0xe3/0x160 [idxd]\n[74412.628963]  idxd_wq_thread+0x1a6/0x2b0 [idxd]\n[74412.634046]  irq_thread_fn+0x21/0x60\n[74412.638134]  ? irq_thread+0xa8/0x290\n[74412.642218]  irq_thread+0x1a0/0x290\n[74412.646212]  ? __pfx_irq_thread_fn+0x10/0x10\n[74412.651071]  ? __pfx_irq_thread_dtor+0x10/0x10\n[74412.656117]  ? __pfx_irq_thread+0x10/0x10\n[74412.660686]  kthread+0x100/0x130\n[74412.664384]  ? __pfx_kthread+0x10/0x10\n[74412.668639]  ret_from_fork+0x31/0x50\n[74412.672716]  ? __pfx_kthread+0x10/0x10\n[74412.676978]  ret_from_fork_asm+0x1a/0x30\n[74412.681457]  \u0026lt;/TASK\u0026gt;\n\nThe cause is due to the idxd driver interrupt completion handler uses\nthreaded interrupt and the threaded handler is not hard or soft interrupt\ncontext. However __netif_rx() can only be called from interrupt context.\nChange the call to netif_rx() in order to allow completion via normal\ncontext for dmaengine drivers that utilize threaded irq handling.\n\nWhile the following commit changed from netif_rx() to __netif_rx(),\nbaebdf48c360 (\u0026quot;net: dev: Makes sure netif_rx() can be invoked in any context.\u0026quot;),\nthe change should\u0026apos;ve been a noop instead. However, the code precedes this\nfix should\u0026apos;ve been using netif_rx_ni() or netif_rx_any_context().(CVE-2024-42110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: page_ref: remove folio_try_get_rcu()\n\nThe below bug was reported on a non-SMP kernel:\n\n[  275.267158][ T4335] ------------[ cut here ]------------\n[  275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275!\n[  275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI\n[  275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6.7.0-rc4-00061-gefa7df3e3bb5 #1\n[  275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n[  275.270679][ T4335] RIP: 0010:try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[  275.272813][ T4335] RSP: 0018:ffffc90005dcf650 EFLAGS: 00010202\n[  275.273346][ T4335] RAX: 0000000000000246 RBX: ffffea00066e0000 RCX: 0000000000000000\n[  275.274032][ T4335] RDX: fffff94000cdc007 RSI: 0000000000000004 RDI: ffffea00066e0034\n[  275.274719][ T4335] RBP: ffffea00066e0000 R08: 0000000000000000 R09: fffff94000cdc006\n[  275.275404][ T4335] R10: ffffea00066e0037 R11: 0000000000000000 R12: 0000000000000136\n[  275.276106][ T4335] R13: ffffea00066e0034 R14: dffffc0000000000 R15: ffffea00066e0008\n[  275.276790][ T4335] FS:  00007fa2f9b61740(0000) GS:ffffffff89d0d000(0000) knlGS:0000000000000000\n[  275.277570][ T4335] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  275.278143][ T4335] CR2: 00007fa2f6c00000 CR3: 0000000134b04000 CR4: 00000000000406f0\n[  275.278833][ T4335] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  275.279521][ T4335] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  275.280201][ T4335] Call Trace:\n[  275.280499][ T4335]  \u0026lt;TASK\u0026gt;\n[ 275.280751][ T4335] ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\n[ 275.281087][ T4335] ? do_trap (arch/x86/kernel/traps.c:112 arch/x86/kernel/traps.c:153)\n[ 275.281463][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.281884][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.282300][ T4335] ? do_error_trap (arch/x86/kernel/traps.c:174)\n[ 275.282711][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283129][ T4335] ? handle_invalid_op (arch/x86/kernel/traps.c:212)\n[ 275.283561][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283990][ T4335] ? exc_invalid_op (arch/x86/kernel/traps.c:264)\n[ 275.284415][ T4335] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:568)\n[ 275.284859][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.285278][ T4335] try_grab_folio (mm/gup.c:148)\n[ 275.285684][ T4335] __get_user_pages (mm/gup.c:1297 (discriminator 1))\n[ 275.286111][ T4335] ? __pfx___get_user_pages (mm/gup.c:1188)\n[ 275.286579][ T4335] ? __pfx_validate_chain (kernel/locking/lockdep.c:3825)\n[ 275.287034][ T4335] ? mark_lock (kernel/locking/lockdep.c:4656 (discriminator 1))\n[ 275.287416][ T4335] __gup_longterm_locked (mm/gup.c:1509 mm/gup.c:2209)\n[ 275.288192][ T4335] ? __pfx___gup_longterm_locked (mm/gup.c:2204)\n[ 275.288697][ T4335] ? __pfx_lock_acquire (kernel/locking/lockdep.c:5722)\n[ 275.289135][ T4335] ? __pfx___might_resched (kernel/sched/core.c:10106)\n[ 275.289595][ T4335] pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290041][ T4335] ? __pfx_pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290545][ T4335] ? find_held_lock (kernel/locking/lockdep.c:5244 (discriminator 1))\n[ 275.290961][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.291353][ T4335] process_vm_rw_single_vec+0x142/0x360\n[ 275.291900][ T4335] ? __pfx_process_vm_rw_single_vec+0x10/0x10\n[ 275.292471][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.292859][ T4335] process_vm_rw_core+0x272/0x4e0\n[ 275.293384][ T4335] ? hlock_class (a\n---truncated---(CVE-2024-42251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix null reference error when checking end of zone\n\nThis patch fixes a potentially null pointer being accessed by\nis_end_zone_blkaddr() that checks the last block of a zone\nwhen f2fs is mounted as a single device.(CVE-2024-43857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exit\n\nWhen a task is scheduled out, pending sigtrap deliveries are deferred\nto the target task upon resume to userspace via task_work.\n\nHowever failures while adding an event\u0026apos;s callback to the task_work\nengine are ignored. And since the last call for events exit happen\nafter task work is eventually closed, there is a small window during\nwhich pending sigtrap can be queued though ignored, leaking the event\nrefcount addition such as in the following scenario:\n\n    TASK A\n    -----\n\n    do_exit()\n       exit_task_work(tsk);\n\n       \u0026lt;IRQ\u0026gt;\n       perf_event_overflow()\n          event-\u0026gt;pending_sigtrap = pending_id;\n          irq_work_queue(\u0026amp;event-\u0026gt;pending_irq);\n       \u0026lt;/IRQ\u0026gt;\n    =========\u0026gt; PREEMPTION: TASK A -\u0026gt; TASK B\n       event_sched_out()\n          event-\u0026gt;pending_sigtrap = 0;\n          atomic_long_inc_not_zero(\u0026amp;event-\u0026gt;refcount)\n          // FAILS: task work has exited\n          task_work_add(\u0026amp;event-\u0026gt;pending_task)\n       [...]\n       \u0026lt;IRQ WORK\u0026gt;\n       perf_pending_irq()\n          // early return: event-\u0026gt;oncpu = -1\n       \u0026lt;/IRQ WORK\u0026gt;\n       [...]\n    =========\u0026gt; TASK B -\u0026gt; TASK A\n       perf_event_exit_task(tsk)\n          perf_event_exit_event()\n             free_event()\n                WARN(atomic_long_cmpxchg(\u0026amp;event-\u0026gt;refcount, 1, 0) != 1)\n                // leak event due to unexpected refcount == 2\n\nAs a result the event is never released while the task exits.\n\nFix this with appropriate task_work_add()\u0026apos;s error handling.(CVE-2024-43870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: Clean up error handling in vpci_scan_bus()\n\nSmatch complains about inconsistent NULL checking in vpci_scan_bus():\n\n    drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed \u0026apos;vpci_bus\u0026apos; could be null (see line 1021)\n\nInstead of printing an error message and then crashing we should return\nan error code and clean up.\n\nAlso the NULL check is reversed so it prints an error for success\ninstead of failure.(CVE-2024-43875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()\n\nAvoid large backtrace, it is sufficient to warn the user that there has\nbeen a link problem. Either the link has failed and the system is in need\nof maintenance, or the link continues to work and user has been informed.\nThe message from the warning can be looked up in the sources.\n\nThis makes an actual link issue less verbose.\n\nFirst of all, this controller has a limitation in that the controller\ndriver has to assist the hardware with transition to L1 link state by\nwriting L1IATN to PMCTRL register, the L1 and L0 link state switching\nis not fully automatic on this controller.\n\nIn case of an ASMedia ASM1062 PCIe SATA controller which does not support\nASPM, on entry to suspend or during platform pm_test, the SATA controller\nenters D3hot state and the link enters L1 state. If the SATA controller\nwakes up before rcar_pcie_wakeup() was called and returns to D0, the link\nreturns to L0 before the controller driver even started its transition to\nL1 link state. At this point, the SATA controller did send an PM_ENTER_L1\nDLLP to the PCIe controller and the PCIe controller received it, and the\nPCIe controller did set PMSR PMEL1RX bit.\n\nOnce rcar_pcie_wakeup() is called, if the link is already back in L0 state\nand PMEL1RX bit is set, the controller driver has no way to determine if\nit should perform the link transition to L1 state, or treat the link as if\nit is in L0 state. Currently the driver attempts to perform the transition\nto L1 link state unconditionally, which in this specific case fails with a\nPMSR L1FAEG poll timeout, however the link still works as it is already\nback in L0 state.\n\nReduce this warning verbosity. In case the link is really broken, the\nrcar_pcie_config_access() would fail, otherwise it will succeed and any\nsystem with this controller and ASM1062 can suspend without generating\na backtrace.(CVE-2024-43876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pci: ivtv: Add check for DMA map result\n\nIn case DMA fails, \u0026apos;dma-\u0026gt;SG_length\u0026apos; is 0. This value is later used to\naccess \u0026apos;dma-\u0026gt;SGarray[dma-\u0026gt;SG_length - 1]\u0026apos;, which will cause out of\nbounds access.\n\nAdd check to return early on invalid value. Adjust warnings accordingly.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43877)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_acl_erp: Fix object nesting warning\n\nACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM\n(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can\ncontain more ACLs (i.e., tc filters), but the number of masks in each\nregion (i.e., tc chain) is limited.\n\nIn order to mitigate the effects of the above limitation, the device\nallows filters to share a single mask if their masks only differ in up\nto 8 consecutive bits. For example, dst_ip/25 can be represented using\ndst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the\nnumber of masks being used (and therefore does not support mask\naggregation), but can contain a limited number of filters.\n\nThe driver uses the \u0026quot;objagg\u0026quot; library to perform the mask aggregation by\npassing it objects that consist of the filter\u0026apos;s mask and whether the\nfilter is to be inserted into the A-TCAM or the C-TCAM since filters in\ndifferent TCAMs cannot share a mask.\n\nThe set of created objects is dependent on the insertion order of the\nfilters and is not necessarily optimal. Therefore, the driver will\nperiodically ask the library to compute a more optimal set (\u0026quot;hints\u0026quot;) by\nlooking at all the existing objects.\n\nWhen the library asks the driver whether two objects can be aggregated\nthe driver only compares the provided masks and ignores the A-TCAM /\nC-TCAM indication. This is the right thing to do since the goal is to\nmove as many filters as possible to the A-TCAM. The driver also forbids\ntwo identical masks from being aggregated since this can only happen if\none was intentionally put in the C-TCAM to avoid a conflict in the\nA-TCAM.\n\nThe above can result in the following set of hints:\n\nH1: {mask X, A-TCAM} -\u0026gt; H2: {mask Y, A-TCAM} // X is Y + delta\nH3: {mask Y, C-TCAM} -\u0026gt; H4: {mask Z, A-TCAM} // Y is Z + delta\n\nAfter getting the hints from the library the driver will start migrating\nfilters from one region to another while consulting the computed hints\nand instructing the device to perform a lookup in both regions during\nthe transition.\n\nAssuming a filter with mask X is being migrated into the A-TCAM in the\nnew region, the hints lookup will return H1. Since H2 is the parent of\nH1, the library will try to find the object associated with it and\ncreate it if necessary in which case another hints lookup (recursive)\nwill be performed. This hints lookup for {mask Y, A-TCAM} will either\nreturn H2 or H3 since the driver passes the library an object comparison\nfunction that ignores the A-TCAM / C-TCAM indication.\n\nThis can eventually lead to nested objects which are not supported by\nthe library [1].\n\nFix by removing the object comparison function from both the driver and\nthe library as the driver was the only user. That way the lookup will\nonly return exact matches.\n\nI do not have a reliable reproducer that can reproduce the issue in a\ntimely manner, but before the fix the issue would reproduce in several\nminutes and with the fix it does not reproduce in over an hour.\n\nNote that the current usefulness of the hints is limited because they\ninclude the C-TCAM indication and represent aggregation that cannot\nactually happen. This will be addressed in net-next.\n\n[1]\nWARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0\nModules linked in:\nCPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42\nHardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __objagg_obj_get+0x2bb/0x580\n objagg_obj_get+0xe/0x80\n mlxsw_sp_acl_erp_mask_get+0xb5/0xf0\n mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370(CVE-2024-43880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: change DMA direction while mapping reinjected packets\n\nFor fragmented packets, ath12k reassembles each fragment as a normal\npacket and then reinjects it into HW ring. In this case, the DMA\ndirection should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,\nan invalid payload may be reinjected into the HW and\nsubsequently delivered to the host.\n\nGiven that arbitrary memory can be allocated to the skb buffer,\nknowledge about the data contained in the reinjected buffer is lacking.\nConsequently, there\u2019s a risk of private information being leaked.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1(CVE-2024-43881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(\u0026amp;ctx-\u0026gt;wqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can\u0026apos;t use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock.(CVE-2024-44957)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntick/broadcast: Move per CPU pointer access into the atomic section\n\nThe recent fix for making the take over of the broadcast timer more\nreliable retrieves a per CPU pointer in preemptible context.\n\nThis went unnoticed as compilers hoist the access into the non-preemptible\nregion where the pointer is actually used. But of course it\u0026apos;s valid that\nthe compiler keeps it at the place where the code puts it which rightfully\ntriggers:\n\n  BUG: using smp_processor_id() in preemptible [00000000] code:\n       caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0\n\nMove it to the actual usage site which is in a non-preemptible region.(CVE-2024-44968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not clear page dirty inside extent_write_locked_range()\n\n[BUG]\nFor subpage + zoned case, the following workload can lead to rsv data\nleak at unmount time:\n\n  # mkfs.btrfs -f -s 4k $dev\n  # mount $dev $mnt\n  # fsstress -w -n 8 -d $mnt -s 1709539240\n  0/0: fiemap - no filename\n  0/1: copyrange read - no filename\n  0/2: write - no filename\n  0/3: rename - no source filename\n  0/4: creat f0 x:0 0 0\n  0/4: creat add id=0,parent=-1\n  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0\n  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1\n  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()\n  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0\n  # umount $mnt\n\nThe dmesg includes the following rsv leak detection warning (all call\ntrace skipped):\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info DATA has 268218368 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n\nAbove $dev is a tcmu-runner emulated zoned HDD, which has a max zone\nappend size of 64K, and the system has 64K page size.\n\n[CAUSE]\nI have added several trace_printk() to show the events (header skipped):\n\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864\n\nThe above lines show our buffered write has dirtied 3 pages of inode\n259 of root 5:\n\n  704K             768K              832K              896K\n  I           |////I/////////////////I///////////|     I\n              756K                               868K\n\n  |///| is the dirtied range using subpage bitmaps. and \u0026apos;I\u0026apos; is the page\n  boundary.\n\n  Meanwhile all three pages (704K, 768K, 832K) have their PageDirty\n  flag set.\n\n  \u0026gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400\n\nThen direct IO writ\n---truncated---(CVE-2024-44972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: fix panic caused by partcmd_update\n\nWe find a bug as below:\nBUG: unable to handle page fault for address: 00000003\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 358 Comm: bash Tainted: G        W I        6.6.0-10893-g60d6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4\nRIP: 0010:partition_sched_domains_locked+0x483/0x600\nCode: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9\nRSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202\nRAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80\nRBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002\nR13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x8c/0xa0\n ? __die_body+0x23/0xa0\n ? __die+0x3a/0x50\n ? page_fault_oops+0x1d2/0x5c0\n ? partition_sched_domains_locked+0x483/0x600\n ? search_module_extables+0x2a/0xb0\n ? search_exception_tables+0x67/0x90\n ? kernelmode_fixup_or_oops+0x144/0x1b0\n ? __bad_area_nosemaphore+0x211/0x360\n ? up_read+0x3b/0x50\n ? bad_area_nosemaphore+0x1a/0x30\n ? exc_page_fault+0x890/0xd90\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? asm_exc_page_fault+0x26/0x30\n ? partition_sched_domains_locked+0x483/0x600\n ? partition_sched_domains_locked+0xf0/0x600\n rebuild_sched_domains_locked+0x806/0xdc0\n update_partition_sd_lb+0x118/0x130\n cpuset_write_resmask+0xffc/0x1420\n cgroup_file_write+0xb2/0x290\n kernfs_fop_write_iter+0x194/0x290\n new_sync_write+0xeb/0x160\n vfs_write+0x16f/0x1d0\n ksys_write+0x81/0x180\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x2f25/0x4630\n do_syscall_64+0x44/0xb0\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\nRIP: 0033:0x7f44a553c887\n\nIt can be reproduced with cammands:\ncd /sys/fs/cgroup/\nmkdir test\ncd test/\necho +cpuset \u0026gt; ../cgroup.subtree_control\necho root \u0026gt; cpuset.cpus.partition\ncat /sys/fs/cgroup/cpuset.cpus.effective\n0-3\necho 0-3 \u0026gt; cpuset.cpus // taking away all cpus from root\n\nThis issue is caused by the incorrect rebuilding of scheduling domains.\nIn this scenario, test/cpuset.cpus.partition should be an invalid root\nand should not trigger the rebuilding of scheduling domains. When calling\nupdate_parent_effective_cpumask with partcmd_update, if newmask is not\nnull, it should recheck newmask whether there are cpus is available\nfor parect/cs that has tasks.(CVE-2024-44975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix RX buf alloc_size alignment and atomic op panic\n\nThe MANA driver\u0026apos;s RX buffer alloc_size is passed into napi_build_skb() to\ncreate SKB. skb_shinfo(skb) is located at the end of skb, and its alignment\nis affected by the alloc_size passed into napi_build_skb(). The size needs\nto be aligned properly for better performance and atomic operations.\nOtherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic\noperations may panic on the skb_shinfo(skb)-\u0026gt;dataref due to alignment fault.\n\nTo fix this bug, add proper alignment to the alloc_size calculation.\n\nSample panic info:\n[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce\n[  253.300900] Mem abort info:\n[  253.301760]   ESR = 0x0000000096000021\n[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  253.304268]   SET = 0, FnV = 0\n[  253.305172]   EA = 0, S1PTW = 0\n[  253.306103]   FSC = 0x21: alignment fault\nCall trace:\n __skb_clone+0xfc/0x198\n skb_clone+0x78/0xe0\n raw6_local_deliver+0xfc/0x228\n ip6_protocol_deliver_rcu+0x80/0x500\n ip6_input_finish+0x48/0x80\n ip6_input+0x48/0xc0\n ip6_sublist_rcv_finish+0x50/0x78\n ip6_sublist_rcv+0x1cc/0x2b8\n ipv6_list_rcv+0x100/0x150\n __netif_receive_skb_list_core+0x180/0x220\n netif_receive_skb_list_internal+0x198/0x2a8\n __napi_poll+0x138/0x250\n net_rx_action+0x148/0x330\n handle_softirqs+0x12c/0x3a0(CVE-2024-45001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: fix validity interception issue when gisa is switched off\n\nWe might run into a SIE validity if gisa has been disabled either via using\nkernel parameter \u0026quot;kvm.use_gisa=0\u0026quot; or by setting the related sysfs\nattribute to N (echo N \u0026gt;/sys/module/kvm/parameters/use_gisa).\n\nThe validity is caused by an invalid value in the SIE control block\u0026apos;s\ngisa designation. That happens because we pass the uninitialized gisa\norigin to virt_to_phys() before writing it to the gisa designation.\n\nTo fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.\nkvm_s390_get_gisa_desc() is used to determine which gisa designation to\nset in the SIE control block. A value of 0 in the gisa designation disables\ngisa usage.\n\nThe issue surfaces in the host kernel with the following kernel message as\nsoon a new kvm guest start is attemted.\n\nkvm: unhandled validity intercept 0x1011\nWARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]\nModules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm 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 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]\nCPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6\nHardware name: IBM 3931 A01 701 (LPAR)\nKrnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])\n           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\nKrnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000\n           000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff\n           000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412\n           000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960\nKrnl Code: 000003d93deb0112: c020fffe7259\tlarl\t%r2,000003d93de7e5c4\n           000003d93deb0118: c0e53fa8beac\tbrasl\t%r14,000003d9bd3c7e70\n          #000003d93deb011e: af000000\t\tmc\t0,0\n          \u0026gt;000003d93deb0122: a728ffea\t\tlhi\t%r2,-22\n           000003d93deb0126: a7f4fe24\t\tbrc\t15,000003d93deafd6e\n           000003d93deb012a: 9101f0b0\t\ttm\t176(%r15),1\n           000003d93deb012e: a774fe48\t\tbrc\t7,000003d93deafdbe\n           000003d93deb0132: 40a0f0ae\t\tsth\t%r10,174(%r15)\nCall Trace:\n [\u0026lt;000003d93deb0122\u0026gt;] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]\n([\u0026lt;000003d93deb011e\u0026gt;] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])\n [\u0026lt;000003d93deacc10\u0026gt;] vcpu_post_run+0x1d0/0x3b0 [kvm]\n [\u0026lt;000003d93deaceda\u0026gt;] __vcpu_run+0xea/0x2d0 [kvm]\n [\u0026lt;000003d93dead9da\u0026gt;] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]\n [\u0026lt;000003d93de93ee0\u0026gt;] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]\n [\u0026lt;000003d9bd728b4e\u0026gt;] vfs_ioctl+0x2e/0x70\n [\u0026lt;000003d9bd72a092\u0026gt;] __s390x_sys_ioctl+0xc2/0xd0\n [\u0026lt;000003d9be0e9222\u0026gt;] __do_syscall+0x1f2/0x2e0\n [\u0026lt;000003d9be0f9a90\u0026gt;] system_call+0x70/0x98\nLast Breaking-Event-Address:\n [\u0026lt;000003d9bd3c7f58\u0026gt;] __warn_printk+0xe8/0xf0(CVE-2024-45005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nchar: xillybus: Don\u0026apos;t destroy workqueue from work item running on it\n\nTriggered by a kref decrement, destroy_workqueue() may be called from\nwithin a work item for destroying its own workqueue. This illegal\nsituation is averted by adding a module-global workqueue for exclusive\nuse of the offending work item. Other work items continue to be queued\non per-device workqueues to ensure performance.(CVE-2024-45007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: use dma non-coherent allocator\n\nCurrently, enabling SG_DEBUG in the kernel will cause nouveau to hit a\nBUG() on startup, when the iommu is enabled:\n\nkernel BUG at include/linux/scatterlist.h:187!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30\nHardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019\nRIP: 0010:sg_init_one+0x85/0xa0\nCode: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54\n24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 \u0026lt;0f\u0026gt; 0b 0f 0b\n0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00\nRSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000\nRBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508\nR13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018\nFS:  00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x36/0x90\n ? do_trap+0xdd/0x100\n ? sg_init_one+0x85/0xa0\n ? do_error_trap+0x65/0x80\n ? sg_init_one+0x85/0xa0\n ? exc_invalid_op+0x50/0x70\n ? sg_init_one+0x85/0xa0\n ? asm_exc_invalid_op+0x1a/0x20\n ? sg_init_one+0x85/0xa0\n nvkm_firmware_ctor+0x14a/0x250 [nouveau]\n nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]\n ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]\n r535_gsp_oneinit+0xb3/0x15f0 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? nvkm_udevice_new+0x95/0x140 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get+0x47/0xb0\n\nFix this by using the non-coherent allocator instead, I think there\nmight be a better answer to this, but it involve ripping up some of\nAPIs using sg lists.(CVE-2024-45012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0\n\nThe __vmap_pages_range_noflush() assumes its argument pages** contains\npages with the same page shift.  However, since commit e9c3cda4d86e (\u0026quot;mm,\nvmalloc: fix high order __GFP_NOFAIL allocations\u0026quot;), if gfp_flags includes\n__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation\nfailed for high order, the pages** may contain two different page shifts\n(high order and order-0).  This could lead __vmap_pages_range_noflush() to\nperform incorrect mappings, potentially resulting in memory corruption.\n\nUsers might encounter this as follows (vmap_allow_huge = true, 2M is for\nPMD_SIZE):\n\nkvmalloc(2M, __GFP_NOFAIL|GFP_X)\n    __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)\n        vm_area_alloc_pages(order=9) ---\u0026gt; order-9 allocation failed and fallback to order-0\n            vmap_pages_range()\n                vmap_pages_range_noflush()\n                    __vmap_pages_range_noflush(page_shift = 21) ----\u0026gt; wrong mapping happens\n\nWe can remove the fallback code because if a high-order allocation fails,\n__vmalloc_node_range_noprof() will retry with order-0.  Therefore, it is\nunnecessary to fallback to order-0 here.  Therefore, fix this by removing\nthe fallback code.(CVE-2024-45022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion\n\nwpa_supplicant 2.11 sends since 1efdba5fdc2c (\u0026quot;Handle PMKSA flush in the\ndriver for SAE/OWE offload cases\u0026quot;) SSID based PMKSA del commands.\nbrcmfmac is not prepared and tries to dereference the NULL bssid and\npmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based\nupdates so copy the SSID.(CVE-2024-46672)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Fix random crash seen while removing driver\n\nThis fixes the random kernel crash seen while removing the driver, when\nrunning the load/unload test over multiple iterations.\n\n1) modprobe btnxpuart\n2) hciconfig hci0 reset\n3) hciconfig (check hci0 interface up with valid BD address)\n4) modprobe -r btnxpuart\nRepeat steps 1 to 4\n\nThe ps_wakeup() call in btnxpuart_close() schedules the psdata-\u0026gt;work(),\nwhich gets scheduled after module is removed, causing a kernel crash.\n\nThis hidden issue got highlighted after enabling Power Save by default\nin 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on\nstartup)\n\nThe new ps_cleanup() deasserts UART break immediately while closing\nserdev device, cancels any scheduled ps_work and destroys the ps_lock\nmutex.\n\n[   85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258\n[   85.884624] Mem abort info:\n[   85.884625]   ESR = 0x0000000086000007\n[   85.884628]   EC = 0x21: IABT (current EL), IL = 32 bits\n[   85.884633]   SET = 0, FnV = 0\n[   85.884636]   EA = 0, S1PTW = 0\n[   85.884638]   FSC = 0x07: level 3 translation fault\n[   85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000\n[   85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000\n[   85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n[   85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]\n[   85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G           O       6.1.36+g937b1be4345a #1\n[   85.936176] Hardware name: FSL i.MX8MM EVK board (DT)\n[   85.936182] Workqueue: events 0xffffd4a61638f380\n[   85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   85.952817] pc : 0xffffd4a61638f258\n[   85.952823] lr : 0xffffd4a61638f258\n[   85.952827] sp : ffff8000084fbd70\n[   85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000\n[   85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305\n[   85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970\n[   85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000\n[   85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090\n[   85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139\n[   85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50\n[   85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8\n[   85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000\n[   85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000\n[   85.977443] Call trace:\n[   85.977446]  0xffffd4a61638f258\n[   85.977451]  0xffffd4a61638f3e8\n[   85.977455]  process_one_work+0x1d4/0x330\n[   85.977464]  worker_thread+0x6c/0x430\n[   85.977471]  kthread+0x108/0x10c\n[   85.977476]  ret_from_fork+0x10/0x20\n[   85.977488] Code: bad PC value\n[   85.977491] ---[ end trace 0000000000000000 ]---\n\nPreset since v6.9.11(CVE-2024-46680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink: Fix race during initialization\n\nAs pointed out by Stephen Boyd it is possible that during initialization\nof the pmic_glink child drivers, the protection-domain notifiers fires,\nand the associated work is scheduled, before the client registration\nreturns and as a result the local \u0026quot;client\u0026quot; pointer has been initialized.\n\nThe outcome of this is a NULL pointer dereference as the \u0026quot;client\u0026quot;\npointer is blindly dereferenced.\n\nTimeline provided by Stephen:\n CPU0                               CPU1\n ----                               ----\n ucsi-\u0026gt;client = NULL;\n devm_pmic_glink_register_client()\n  client-\u0026gt;pdr_notify(client-\u0026gt;priv, pg-\u0026gt;client_state)\n   pmic_glink_ucsi_pdr_notify()\n    schedule_work(\u0026amp;ucsi-\u0026gt;register_work)\n    \u0026lt;schedule away\u0026gt;\n                                    pmic_glink_ucsi_register()\n                                     ucsi_register()\n                                      pmic_glink_ucsi_read_version()\n                                       pmic_glink_ucsi_read()\n                                        pmic_glink_ucsi_read()\n                                         pmic_glink_send(ucsi-\u0026gt;client)\n                                         \u0026lt;client is NULL BAD\u0026gt;\n ucsi-\u0026gt;client = client // Too late!\n\nThis code is identical across the altmode, battery manager and usci\nchild drivers.\n\nResolve this by splitting the allocation of the \u0026quot;client\u0026quot; object and the\nregistration thereof into two operations.\n\nThis only happens if the protection domain registry is populated at the\ntime of registration, which by the introduction of commit \u0026apos;1ebcde047c54\n(\u0026quot;soc: qcom: add pd-mapper implementation\u0026quot;)\u0026apos; became much more likely.(CVE-2024-46693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid using null object of framebuffer\n\nInstead of using state-\u0026gt;fb-\u0026gt;obj[0] directly, get object from framebuffer\nby calling drm_gem_fb_get_obj() and return error code when object is\nnull to avoid using null object of framebuffer.\n\n(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)(CVE-2024-46694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: fix ID 0 endp usage after multiple re-creations\n\n\u0026apos;local_addr_used\u0026apos; and \u0026apos;add_addr_accepted\u0026apos; are decremented for addresses\nnot related to the initial subflow (ID0), because the source and\ndestination addresses of the initial subflows are known from the\nbeginning: they don\u0026apos;t count as \u0026quot;additional local address being used\u0026quot; or\n\u0026quot;ADD_ADDR being accepted\u0026quot;.\n\nIt is then required not to increment them when the entrypoint used by\nthe initial subflow is removed and re-added during a connection. Without\nthis modification, this entrypoint cannot be removed and re-added more\nthan once.(CVE-2024-46711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix double free of \u0026apos;buf\u0026apos; in error path\n\nsmatch warning:\ndrivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of \u0026apos;buf\u0026apos;\n\nIn fastrpc_req_mmap() error path, the fastrpc buffer is freed in\nfastrpc_req_munmap_impl() if unmap is successful.\n\nBut in the end, there is an unconditional call to fastrpc_buf_free().\nSo the above case triggers the double free of fastrpc buf.(CVE-2024-46741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: void array out of bound when loop tnl_num\n\nWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comes\nfrom hardware and the length of array is a fixed value. To void array out\nof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: ensure vmap_block is initialised before adding to queue\n\nCommit 8c61291fd850 (\u0026quot;mm: fix incorrect vbq reference in\npurge_fragmented_block\u0026quot;) extended the \u0026apos;vmap_block\u0026apos; structure to contain a\n\u0026apos;cpu\u0026apos; field which is set at allocation time to the id of the initialising\nCPU.\n\nWhen a new \u0026apos;vmap_block\u0026apos; is being instantiated by new_vmap_block(), the\npartially initialised structure is added to the local \u0026apos;vmap_block_queue\u0026apos;\nxarray before the \u0026apos;cpu\u0026apos; field has been initialised.  If another CPU is\nconcurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it\nmay perform an out-of-bounds access to the remote queue thanks to an\nuninitialised index.\n\nThis has been observed as UBSAN errors in Android:\n\n | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n |\n | Call trace:\n |  purge_fragmented_block+0x204/0x21c\n |  _vm_unmap_aliases+0x170/0x378\n |  vm_unmap_aliases+0x1c/0x28\n |  change_memory_common+0x1dc/0x26c\n |  set_memory_ro+0x18/0x24\n |  module_enable_ro+0x98/0x238\n |  do_init_module+0x1b0/0x310\n\nMove the initialisation of \u0026apos;vb-\u0026gt;cpu\u0026apos; in new_vmap_block() ahead of the\naddition to the xarray.(CVE-2024-46847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/hyperv: fix kexec crash due to VP assist page corruption\n\ncommit 9636be85cc5b (\u0026quot;x86/hyperv: Fix hyperv_pcpu_input_arg handling when\nCPUs go online/offline\u0026quot;) introduces a new cpuhp state for hyperv\ninitialization.\n\ncpuhp_setup_state() returns the state number if state is\nCPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.\nFor the hyperv case, since a new cpuhp state was introduced it would\nreturn 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call\nis conditioned upon \u0026quot;hyperv_init_cpuhp \u0026gt; 0\u0026quot;. This will never be true and\nso hv_cpu_die() won\u0026apos;t be called on all CPUs. This means the VP assist page\nwon\u0026apos;t be reset. When the kexec kernel tries to setup the VP assist page\nagain, the hypervisor corrupts the memory region of the old VP assist page\ncausing a panic in case the kexec kernel is using that memory elsewhere.\nThis was originally fixed in commit dfe94d4086e4 (\u0026quot;x86/hyperv: Fix kexec\npanic/hang issues\u0026quot;).\n\nGet rid of hyperv_init_cpuhp entirely since we are no longer using a\ndynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with\ncpuhp_remove_state().(CVE-2024-46864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfou: fix initialization of grc\n\nThe grc must be initialize first. There can be a condition where if\nfou is NULL, goto out will be executed and grc would be used\nuninitialized.(CVE-2024-46865)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - inject error before stopping queue\n\nThe master ooo cannot be completely closed when the\naccelerator core reports memory error. Therefore, the driver\nneeds to inject the qm error to close the master ooo. Currently,\nthe qm error is injected after stopping queue, memory may be\nreleased immediately after stopping queue, causing the device to\naccess the released memory. Therefore, error is injected to close master\nooo before stopping queue to ensure that the device does not access\nthe released memory.(CVE-2024-47730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled\n\nFix missuse of spin_lock_irq()/spin_unlock_irq() when\nspin_lock_irqsave()/spin_lock_irqrestore() was hold.\n\nThis was discovered through the lock debugging, and the corresponding\nlog is as follows:\n\nraw_local_irq_restore() called with IRQs enabled\nWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40\n...\nCall trace:\n warn_bogus_irq_restore+0x30/0x40\n _raw_spin_unlock_irqrestore+0x84/0xc8\n add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]\n hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]\n hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]\n create_qp+0x138/0x258\n ib_create_qp_kernel+0x50/0xe8\n create_mad_qp+0xa8/0x128\n ib_mad_port_open+0x218/0x448\n ib_mad_init_device+0x70/0x1f8\n add_client_context+0xfc/0x220\n enable_device_and_get+0xd0/0x140\n ib_register_device.part.0+0xf4/0x1c8\n ib_register_device+0x34/0x50\n hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]\n hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]\n hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix a race between socket set up and I/O thread creation\n\nIn rxrpc_open_socket(), it sets up the socket and then sets up the I/O\nthread that will handle it.  This is a problem, however, as there\u0026apos;s a gap\nbetween the two phases in which a packet may come into rxrpc_encap_rcv()\nfrom the UDP packet but we oops when trying to wake the not-yet created I/O\nthread.\n\nAs a quick fix, just make rxrpc_encap_rcv() discard the packet if there\u0026apos;s\nno I/O thread yet.\n\nA better, but more intrusive fix would perhaps be to rearrange things such\nthat the socket creation is done by the I/O thread.(CVE-2024-49864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a sdiv overflow issue\n\nZac Ecob reported a problem where a bpf program may cause kernel crash due\nto the following error:\n  Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\n\nThe failure is due to the below signed divide:\n  LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808.\nLLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808,\nbut it is impossible since for 64-bit system, the maximum positive\nnumber is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will\ncause a kernel exception. On arm64, the result for LLONG_MIN/-1 is\nLLONG_MIN.\n\nFurther investigation found all the following sdiv/smod cases may trigger\nan exception when bpf program is running on x86_64 platform:\n  - LLONG_MIN/-1 for 64bit operation\n  - INT_MIN/-1 for 32bit operation\n  - LLONG_MIN%-1 for 64bit operation\n  - INT_MIN%-1 for 32bit operation\nwhere -1 can be an immediate or in a register.\n\nOn arm64, there are no exceptions:\n  - LLONG_MIN/-1 = LLONG_MIN\n  - INT_MIN/-1 = INT_MIN\n  - LLONG_MIN%-1 = 0\n  - INT_MIN%-1 = 0\nwhere -1 can be an immediate or in a register.\n\nInsn patching is needed to handle the above cases and the patched codes\nproduced results aligned with above arm64 result. The below are pseudo\ncodes to handle sdiv/smod exceptions including both divisor -1 and divisor 0\nand the divisor is stored in a register.\n\nsdiv:\n      tmp = rX\n      tmp += 1 /* [-1, 0] -\u0026gt; [0, 1]\n      if tmp \u0026gt;(unsigned) 1 goto L2\n      if tmp == 0 goto L1\n      rY = 0\n  L1:\n      rY = -rY;\n      goto L3\n  L2:\n      rY /= rX\n  L3:\n\nsmod:\n      tmp = rX\n      tmp += 1 /* [-1, 0] -\u0026gt; [0, 1]\n      if tmp \u0026gt;(unsigned) 1 goto L1\n      if tmp == 1 (is64 ? goto L2 : goto L3)\n      rY = 0;\n      goto L2\n  L1:\n      rY %= rX\n  L2:\n      goto L4  // only when !is64\n  L3:\n      wY = wY  // only when !is64\n  L4:\n\n  [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/(CVE-2024-49888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()\n\nFor kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is\ndefined as NR_CPUS instead of the number of possible cpus, this\nwill cause the following system panic:\n\nsmpboot: Allowing 4 CPUs, 0 hotplug CPUs\n...\nsetup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1\n...\nBUG: unable to handle page fault for address: ffffffff9911c8c8\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W\n6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6\nRIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0\nRSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082\nCR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? __die+0x23/0x80\n? page_fault_oops+0xa4/0x180\n? exc_page_fault+0x152/0x180\n? asm_exc_page_fault+0x26/0x40\n? rcu_tasks_need_gpcb+0x25d/0x2c0\n? __pfx_rcu_tasks_kthread+0x40/0x40\nrcu_tasks_one_gp+0x69/0x180\nrcu_tasks_kthread+0x94/0xc0\nkthread+0xe8/0x140\n? __pfx_kthread+0x40/0x40\nret_from_fork+0x34/0x80\n? __pfx_kthread+0x40/0x40\nret_from_fork_asm+0x1b/0x80\n\u0026lt;/TASK\u0026gt;\n\nConsidering that there may be holes in the CPU numbers, use the\nmaximum possible cpu number, instead of nr_cpu_ids, for configuring\nenqueue and dequeue limits.\n\n[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ](CVE-2024-49926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: avoid to add interface to list twice when SER\n\nIf SER L2 occurs during the WoWLAN resume flow, the add interface flow\nis triggered by ieee80211_reconfig(). However, due to\nrtw89_wow_resume() return failure, it will cause the add interface flow\nto be executed again, resulting in a double add list and causing a kernel\npanic. Therefore, we have added a check to prevent double adding of the\nlist.\n\nlist_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:37!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7\nHardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021\nWorkqueue: events_freezable ieee80211_restart_work [mac80211]\nRIP: 0010:__list_add_valid_or_report+0x5e/0xb0\nCode: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 \u0026lt;0f\u0026gt; 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12\nRSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900\nRDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001\nRBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0\nR10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060\nR13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010\nFS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1f/0x70\n ? die+0x3d/0x60\n ? do_trap+0xa4/0x110\n ? __list_add_valid_or_report+0x5e/0xb0\n ? do_error_trap+0x6d/0x90\n ? __list_add_valid_or_report+0x5e/0xb0\n ? handle_invalid_op+0x30/0x40\n ? __list_add_valid_or_report+0x5e/0xb0\n ? exc_invalid_op+0x3c/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_add_valid_or_report+0x5e/0xb0\n rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]\n drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ? finish_wait+0x3e/0x90\n ? synchronize_rcu_expedited+0x174/0x260\n ? sync_rcu_exp_done_unlocked+0x50/0x50\n ? wake_bit_function+0x40/0x40\n ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n process_scheduled_works+0x1e5/0x480\n worker_thread+0xea/0x1e0\n kthread+0xdb/0x110\n ? move_linked_works+0x90/0x90\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork+0x3b/0x50\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\nModules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev\ngsmi: Log Shutdown Reason 0x03\n---[ end trace 0000000000000000 ]---(CVE-2024-49939)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: do not assume bh is held in ppp_channel_bridge_input()\n\nNetworking receive path is usually handled from BH handler.\nHowever, some protocols need to acquire the socket lock, and\npackets might be stored in the socket backlog is the socket was\nowned by a user process.\n\nIn this case, release_sock(), __release_sock(), and sk_backlog_rcv()\nmight call the sk-\u0026gt;sk_backlog_rcv() handler in process context.\n\nsybot caught ppp was not considering this case in\nppp_channel_bridge_input() :\n\nWARNING: inconsistent lock state\n6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted\n--------------------------------\ninconsistent {SOFTIRQ-ON-W} -\u0026gt; {IN-SOFTIRQ-W} usage.\nksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304\n{SOFTIRQ-ON-W} state was registered at:\n   lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759\n   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n   _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154\n   spin_lock include/linux/spinlock.h:351 [inline]\n   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]\n   ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304\n   pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379\n   sk_backlog_rcv include/net/sock.h:1111 [inline]\n   __release_sock+0x1a8/0x3d8 net/core/sock.c:3004\n   release_sock+0x68/0x1b8 net/core/sock.c:3558\n   pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903\n   sock_sendmsg_nosec net/socket.c:730 [inline]\n   __sock_sendmsg net/socket.c:745 [inline]\n   __sys_sendto+0x374/0x4f4 net/socket.c:2204\n   __do_sys_sendto net/socket.c:2216 [inline]\n   __se_sys_sendto net/socket.c:2212 [inline]\n   __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\n   el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nirq event stamp: 282914\n hardirqs last  enabled at (282914): [\u0026lt;ffff80008b42e30c\u0026gt;] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]\n hardirqs last  enabled at (282914): [\u0026lt;ffff80008b42e30c\u0026gt;] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194\n hardirqs last disabled at (282913): [\u0026lt;ffff80008b42e13c\u0026gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\n hardirqs last disabled at (282913): [\u0026lt;ffff80008b42e13c\u0026gt;] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162\n softirqs last  enabled at (282904): [\u0026lt;ffff8000801f8e88\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\n softirqs last  enabled at (282904): [\u0026lt;ffff8000801f8e88\u0026gt;] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582\n softirqs last disabled at (282909): [\u0026lt;ffff8000801fbdf8\u0026gt;] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n       CPU0\n       ----\n  lock(\u0026amp;pch-\u0026gt;downl);\n  \u0026lt;Interrupt\u0026gt;\n    lock(\u0026amp;pch-\u0026gt;downl);\n\n *** DEADLOCK ***\n\n1 lock held by ksoftirqd/1/24:\n  #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall trace:\n  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319\n  show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326\n  __dump_sta\n---truncated---(CVE-2024-49946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible crash on mgmt_index_removed\n\nIf mgmt_index_removed is called while there are commands queued on\ncmd_sync it could lead to crashes like the bellow trace:\n\n0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc\n0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]\n0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]\n0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]\n\nSo while handling mgmt_index_removed this attempts to dequeue\ncommands passed as user_data to cmd_sync.(CVE-2024-49951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice\n\nThe km.state is not checked in driver\u0026apos;s delayed work. When\nxfrm_state_check_expire() is called, the state can be reset to\nXFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This\nhappens when xfrm state is deleted, but not freed yet. As\n__xfrm_state_delete() is called again in xfrm timer, the following\ncrash occurs.\n\nTo fix this issue, skip xfrm_state_check_expire() if km.state is not\nXFRM_STATE_VALID.\n\n Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]\n RIP: 0010:__xfrm_state_delete+0x3d/0x1b0\n Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 \u0026lt;48\u0026gt; 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48\n RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246\n RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036\n RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980\n RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000\n R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246\n R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400\n FS:  0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  ? die_addr+0x33/0x90\n  ? exc_general_protection+0x1a2/0x390\n  ? asm_exc_general_protection+0x22/0x30\n  ? __xfrm_state_delete+0x3d/0x1b0\n  ? __xfrm_state_delete+0x2f/0x1b0\n  xfrm_timer_handler+0x174/0x350\n  ? __xfrm_state_delete+0x1b0/0x1b0\n  __hrtimer_run_queues+0x121/0x270\n  hrtimer_run_softirq+0x88/0xd0\n  handle_softirqs+0xcc/0x270\n  do_softirq+0x3c/0x50\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  __local_bh_enable_ip+0x47/0x50\n  mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]\n  process_one_work+0x137/0x2d0\n  worker_thread+0x28d/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;(CVE-2024-49953)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpftool: Fix undefined behavior in qsort(NULL, 0, ...)\n\nWhen netfilter has no entry to display, qsort is called with\nqsort(NULL, 0, ...). This results in undefined behavior, as UBSan\nreports:\n\nnet.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null\n\nAlthough the C standard does not explicitly state whether calling qsort\nwith a NULL pointer when the size is 0 constitutes undefined behavior,\nSection 7.1.4 of the C standard (Use of library functions) mentions:\n\n\u0026quot;Each of the following statements applies unless explicitly stated\notherwise in the detailed descriptions that follow: If an argument to a\nfunction has an invalid value (such as a value outside the domain of\nthe function, or a pointer outside the address space of the program, or\na null pointer, or a pointer to non-modifiable storage when the\ncorresponding parameter is not const-qualified) or a type (after\npromotion) not expected by a function with variable number of\narguments, the behavior is undefined.\u0026quot;\n\nTo avoid this, add an early return when nf_link_info is NULL to prevent\ncalling qsort with a NULL pointer.(CVE-2024-49987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add refcnt to ksmbd_conn struct\n\nWhen sending an oplock break request, opinfo-\u0026gt;conn is used,\nBut freed -\u0026gt;conn can be used on multichannel.\nThis patch add a reference count to the ksmbd_conn struct\nso that it can be freed when it is no longer used.(CVE-2024-49988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: improve shutdown sequence\n\nAlexander Sverdlin presents 2 problems during shutdown with the\nlan9303 driver. One is specific to lan9303 and the other just happens\nto reproduce there.\n\nThe first problem is that lan9303 is unique among DSA drivers in that it\ncalls dev_get_drvdata() at \u0026quot;arbitrary runtime\u0026quot; (not probe, not shutdown,\nnot remove):\n\nphy_state_machine()\n-\u0026gt; ...\n   -\u0026gt; dsa_user_phy_read()\n      -\u0026gt; ds-\u0026gt;ops-\u0026gt;phy_read()\n         -\u0026gt; lan9303_phy_read()\n            -\u0026gt; chip-\u0026gt;ops-\u0026gt;phy_read()\n               -\u0026gt; lan9303_mdio_phy_read()\n                  -\u0026gt; dev_get_drvdata()\n\nBut we never stop the phy_state_machine(), so it may continue to run\nafter dsa_switch_shutdown(). Our common pattern in all DSA drivers is\nto set drvdata to NULL to suppress the remove() method that may come\nafterwards. But in this case it will result in an NPD.\n\nThe second problem is that the way in which we set\ndp-\u0026gt;conduit-\u0026gt;dsa_ptr = NULL; is concurrent with receive packet\nprocessing. dsa_switch_rcv() checks once whether dev-\u0026gt;dsa_ptr is NULL,\nbut afterwards, rather than continuing to use that non-NULL value,\ndev-\u0026gt;dsa_ptr is dereferenced again and again without NULL checks:\ndsa_conduit_find_user() and many other places. In between dereferences,\nthere is no locking to ensure that what was valid once continues to be\nvalid.\n\nBoth problems have the common aspect that closing the conduit interface\nsolves them.\n\nIn the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN\nevent in dsa_user_netdevice_event() which closes user ports as well.\ndsa_port_disable_rt() calls phylink_stop(), which synchronously stops\nthe phylink state machine, and ds-\u0026gt;ops-\u0026gt;phy_read() will thus no longer\ncall into the driver after this point.\n\nIn the second case, dev_close(conduit) should do this, as per\nDocumentation/networking/driver.rst:\n\n| Quiescence\n| ----------\n|\n| After the ndo_stop routine has been called, the hardware must\n| not receive or transmit any data.  All in flight packets must\n| be aborted. If necessary, poll or wait for completion of\n| any reset commands.\n\nSo it should be sufficient to ensure that later, when we zeroize\nconduit-\u0026gt;dsa_ptr, there will be no concurrent dsa_switch_rcv() call\non this conduit.\n\nThe addition of the netif_device_detach() function is to ensure that\nioctls, rtnetlinks and ethtool requests on the user ports no longer\npropagate down to the driver - we\u0026apos;re no longer prepared to handle them.\n\nThe race condition actually did not exist when commit 0650bf52b31f\n(\u0026quot;net: dsa: be compatible with masters which unregister on shutdown\u0026quot;)\nfirst introduced dsa_switch_shutdown(). It was created later, when we\nstopped unregistering the user interfaces from a bad spot, and we just\nreplaced that sequence with a racy zeroization of conduit-\u0026gt;dsa_ptr\n(one which doesn\u0026apos;t ensure that the interfaces aren\u0026apos;t up).(CVE-2024-49998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix ppp_async_encode() illegal access\n\nsyzbot reported an issue in ppp_async_encode() [1]\n\nIn this case, pppoe_sendmsg() is called with a zero size.\nThen ppp_async_encode() is called with an empty skb.\n\nBUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634\n  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]\n  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304\n  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379\n  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113\n  __release_sock+0x1da/0x330 net/core/sock.c:3072\n  release_sock+0x6b/0x250 net/core/sock.c:3626\n  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903\n  sock_sendmsg_nosec net/socket.c:729 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:744\n  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n  __do_sys_sendmmsg net/socket.c:2771 [inline]\n  __se_sys_sendmmsg net/socket.c:2768 [inline]\n  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4092 [inline]\n  slab_alloc_node mm/slub.c:4135 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n  alloc_skb include/linux/skbuff.h:1322 [inline]\n  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732\n  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867\n  sock_sendmsg_nosec net/socket.c:729 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:744\n  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n  __do_sys_sendmmsg net/socket.c:2771 [inline]\n  __se_sys_sendmmsg net/socket.c:2768 [inline]\n  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Fix multiple init when debugfs is disabled\n\nIf bt_debugfs is not created successfully, which happens if either\nCONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init()\nreturns early and does not set iso_inited to true. This means that a\nsubsequent call to iso_init() will result in duplicate calls to\nproto_register(), bt_sock_register(), etc.\n\nWith CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the\nduplicate call to proto_register() triggers this BUG():\n\n  list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,\n    next=ffffffffc0b280d0.\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:35!\n  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1\n  RIP: 0010:__list_add_valid_or_report+0x9a/0xa0\n  ...\n    __list_add_valid_or_report+0x9a/0xa0\n    proto_register+0x2b5/0x340\n    iso_init+0x23/0x150 [bluetooth]\n    set_iso_socket_func+0x68/0x1b0 [bluetooth]\n    kmem_cache_free+0x308/0x330\n    hci_sock_sendmsg+0x990/0x9e0 [bluetooth]\n    __sock_sendmsg+0x7b/0x80\n    sock_write_iter+0x9a/0x110\n    do_iter_readv_writev+0x11d/0x220\n    vfs_writev+0x180/0x3e0\n    do_writev+0xca/0x100\n  ...\n\nThis change removes the early return. The check for iso_debugfs being\nNULL was unnecessary, it is always NULL when iso_inited is false.(CVE-2024-50077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error\n\nThe `nouveau_dmem_copy_one` function ensures that the copy push command is\nsent to the device firmware but does not track whether it was executed\nsuccessfully.\n\nIn the case of a copy error (e.g., firmware or hardware failure), the\ncopy push command will be sent via the firmware channel, and\n`nouveau_dmem_copy_one` will likely report success, leading to the\n`migrate_to_ram` function returning a dirty HIGH_USER page to the user.\n\nThis can result in a security vulnerability, as a HIGH_USER page that may\ncontain sensitive or corrupted data could be returned to the user.\n\nTo prevent this vulnerability, we allocate a zero page. Thus, in case of\nan error, a non-dirty (zero) page will be returned to the user.(CVE-2024-50096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix one more kernel-infoleak in algo dumping\n\nDuring fuzz testing, the following issue was discovered:\n\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30\n _copy_to_iter+0x598/0x2a30\n __skb_datagram_iter+0x168/0x1060\n skb_copy_datagram_iter+0x5b/0x220\n netlink_recvmsg+0x362/0x1700\n sock_recvmsg+0x2dc/0x390\n __sys_recvfrom+0x381/0x6d0\n __x64_sys_recvfrom+0x130/0x200\n x64_sys_call+0x32c8/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nUninit was stored to memory at:\n copy_to_user_state_extra+0xcc1/0x1e00\n dump_one_state+0x28c/0x5f0\n xfrm_state_walk+0x548/0x11e0\n xfrm_dump_sa+0x1e0/0x840\n netlink_dump+0x943/0x1c40\n __netlink_dump_start+0x746/0xdb0\n xfrm_user_rcv_msg+0x429/0xc00\n netlink_rcv_skb+0x613/0x780\n xfrm_netlink_rcv+0x77/0xc0\n netlink_unicast+0xe90/0x1280\n netlink_sendmsg+0x126d/0x1490\n __sock_sendmsg+0x332/0x3d0\n ____sys_sendmsg+0x863/0xc30\n ___sys_sendmsg+0x285/0x3e0\n __x64_sys_sendmsg+0x2d6/0x560\n x64_sys_call+0x1316/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nUninit was created at:\n __kmalloc+0x571/0xd30\n attach_auth+0x106/0x3e0\n xfrm_add_sa+0x2aa0/0x4230\n xfrm_user_rcv_msg+0x832/0xc00\n netlink_rcv_skb+0x613/0x780\n xfrm_netlink_rcv+0x77/0xc0\n netlink_unicast+0xe90/0x1280\n netlink_sendmsg+0x126d/0x1490\n __sock_sendmsg+0x332/0x3d0\n ____sys_sendmsg+0x863/0xc30\n ___sys_sendmsg+0x285/0x3e0\n __x64_sys_sendmsg+0x2d6/0x560\n x64_sys_call+0x1316/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nBytes 328-379 of 732 are uninitialized\nMemory access of size 732 starts at ffff88800e18e000\nData copied to user address 00007ff30f48aff0\n\nCPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n\nFixes copying of xfrm algorithms where some random\ndata of the structure fields can end up in userspace.\nPadding in structures may be filled with random (possibly sensitve)\ndata and should never be given directly to user-space.\n\nA similar issue was resolved in the commit\n8222d5910dae (\u0026quot;xfrm: Zero padding when dumping algos and encap\u0026quot;)\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-50110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Enable IRQ if do_ale() triggered in irq-enabled context\n\nUnaligned access exception can be triggered in irq-enabled context such\nas user mode, in this case do_ale() may call get_user() which may cause\nsleep. Then we will get:\n\n BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7\n in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe\n preempt_count: 0, expected: 0\n RCU nest depth: 0, expected: 0\n CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G        W          6.12.0-rc1+ #1723\n Tainted: [W]=WARN\n Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000\n         9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000\n         9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890\n         ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500\n         000000000000020c 000000000000000a 0000000000000000 0000000000000003\n         00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260\n         0000000000000000 0000000000000000 9000000005437650 90000000055d5000\n         0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000\n         0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec\n         00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d\n         ...\n Call Trace:\n [\u0026lt;9000000003803964\u0026gt;] show_stack+0x64/0x1a0\n [\u0026lt;9000000004c57464\u0026gt;] dump_stack_lvl+0x74/0xb0\n [\u0026lt;9000000003861ab4\u0026gt;] __might_resched+0x154/0x1a0\n [\u0026lt;900000000380c96c\u0026gt;] emulate_load_store_insn+0x6c/0xf60\n [\u0026lt;9000000004c58118\u0026gt;] do_ale+0x78/0x180\n [\u0026lt;9000000003801bc8\u0026gt;] handle_ale+0x128/0x1e0\n\nSo enable IRQ if unaligned access exception is triggered in irq-enabled\ncontext to fix it.(CVE-2024-50111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Unregister notifier on eswitch init failure\n\nIt otherwise remains registered and a subsequent attempt at eswitch\nenabling might trigger warnings of the sort:\n\n[  682.589148] ------------[ cut here ]------------\n[  682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered\n[  682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90\n[...snipped]\n[  682.610052] Call Trace:\n[  682.610369]  \u0026lt;TASK\u0026gt;\n[  682.610663]  ? __warn+0x7c/0x110\n[  682.611050]  ? notifier_chain_register+0x3e/0x90\n[  682.611556]  ? report_bug+0x148/0x170\n[  682.611977]  ? handle_bug+0x36/0x70\n[  682.612384]  ? exc_invalid_op+0x13/0x60\n[  682.612817]  ? asm_exc_invalid_op+0x16/0x20\n[  682.613284]  ? notifier_chain_register+0x3e/0x90\n[  682.613789]  atomic_notifier_chain_register+0x25/0x40\n[  682.614322]  mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]\n[  682.614965]  mlx5_eswitch_enable+0xc9/0x100 [mlx5_core]\n[  682.615551]  mlx5_device_enable_sriov+0x25/0x340 [mlx5_core]\n[  682.616170]  mlx5_core_sriov_configure+0x50/0x170 [mlx5_core]\n[  682.616789]  sriov_numvfs_store+0xb0/0x1b0\n[  682.617248]  kernfs_fop_write_iter+0x117/0x1a0\n[  682.617734]  vfs_write+0x231/0x3f0\n[  682.618138]  ksys_write+0x63/0xe0\n[  682.618536]  do_syscall_64+0x4c/0x100\n[  682.618958]  entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2024-50136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix command bitmask initialization\n\nCommand bitmask have a dedicated bit for MANAGE_PAGES command, this bit\nisn\u0026apos;t Initialize during command bitmask Initialization, only during\nMANAGE_PAGES.\n\nIn addition, mlx5_cmd_trigger_completions() is trying to trigger\ncompletion for MANAGE_PAGES command as well.\n\nHence, in case health error occurred before any MANAGE_PAGES command\nhave been invoke (for example, during mlx5_enable_hca()),\nmlx5_cmd_trigger_completions() will try to trigger completion for\nMANAGE_PAGES command, which will result in null-ptr-deref error.[1]\n\nFix it by Initialize command bitmask correctly.\n\nWhile at it, re-write the code for better understanding.\n\n[1]\nBUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\nWrite of size 4 at addr 0000000000000214 by task kworker/u96:2/12078\nCPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7e/0xc0\n kasan_report+0xb9/0xf0\n kasan_check_range+0xec/0x190\n mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\n mlx5_cmd_flush+0x94/0x240 [mlx5_core]\n enter_error_state+0x6c/0xd0 [mlx5_core]\n mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]\n process_one_work+0x787/0x1490\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? pwq_dec_nr_in_flight+0xda0/0xda0\n ? assign_work+0x168/0x240\n worker_thread+0x586/0xd30\n ? rescuer_thread+0xae0/0xae0\n kthread+0x2df/0x3b0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x70\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2024-50147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/cs8409: Fix possible NULL dereference\n\nIf snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then\nNULL pointer dereference will occur in the next line.\n\nSince dolphin_fixups function is a hda_fixup function which is not supposed\nto return any errors, add simple check before dereference, ignore the fail.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: qcom: camss: Remove use_count guard in stop_streaming\n\nThe use_count check was introduced so that multiple concurrent Raw Data\nInterfaces RDIs could be driven by different virtual channels VCs on the\nCSIPHY input driving the video pipeline.\n\nThis is an invalid use of use_count though as use_count pertains to the\nnumber of times a video entity has been opened by user-space not the number\nof active streams.\n\nIf use_count and stream-on count don\u0026apos;t agree then stop_streaming() will\nbreak as is currently the case and has become apparent when using CAMSS\nwith libcamera\u0026apos;s released softisp 0.3.\n\nThe use of use_count like this is a bit hacky and right now breaks regular\nusage of CAMSS for a single stream case. Stopping qcam results in the splat\nbelow, and then it cannot be started again and any attempts to do so fails\nwith -EBUSY.\n\n[ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]\n...\n[ 1265.510630] Call trace:\n[ 1265.510636]  __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]\n[ 1265.510648]  vb2_core_streamoff+0x24/0xcc [videobuf2_common]\n[ 1265.510660]  vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2]\n[ 1265.510673]  v4l_streamoff+0x24/0x30 [videodev]\n[ 1265.510707]  __video_do_ioctl+0x190/0x3f4 [videodev]\n[ 1265.510732]  video_usercopy+0x304/0x8c4 [videodev]\n[ 1265.510757]  video_ioctl2+0x18/0x34 [videodev]\n[ 1265.510782]  v4l2_ioctl+0x40/0x60 [videodev]\n...\n[ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state\n[ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state\n[ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st\n\nOne CAMSS specific way to handle multiple VCs on the same RDI might be:\n\n- Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx.\n- The video buffers are already associated with msm_vfeN_rdiX so\n  release video buffers when told to do so by stop_streaming.\n- Only release the power-domains for the CSIPHY, CSID and VFE when\n  their internal refcounts drop.\n\nEither way refusing to release video buffers based on use_count is\nerroneous and should be reverted. The silicon enabling code for selecting\nVCs is perfectly fine. Its a \u0026quot;known missing feature\u0026quot; that concurrent VCs\nwon\u0026apos;t work with CAMSS right now.\n\nInitial testing with this code didn\u0026apos;t show an error but, SoftISP and \u0026quot;real\u0026quot;\nusage with Google Hangouts breaks the upstream code pretty quickly, we need\nto do a partial revert and take another pass at VCs.\n\nThis commit partially reverts commit 89013969e232 (\u0026quot;media: camss: sm8250:\nPipeline starting and stopping for multiple virtual channels\u0026quot;)(CVE-2024-50175)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: k3-r5: Fix error handling when power-up failed\n\nBy simply bailing out, the driver was violating its rule and internal\nassumptions that either both or no rproc should be initialized. E.g.,\nthis could cause the first core to be available but not the second one,\nleading to crashes on its shutdown later on while trying to dereference\nthat second instance.(CVE-2024-50176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D\n\nFor i.MX7D DRAM related mux clock, the clock source change should ONLY\nbe done done in low level asm code without accessing DRAM, and then\ncalling clk API to sync the HW clock status with clk tree, it should never\ntouch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag\nshould NOT be added, otherwise, DRAM\u0026apos;s clock parent will be disabled when\nDRAM is active, and system will hang.(CVE-2024-50181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance\n\nDeleting an NPIV instance requires all fabric ndlps to be released before\nan NPIV\u0026apos;s resources can be torn down.  Failure to release fabric ndlps\nbeforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID\nto complete synchronously with usage of wait_queue.(CVE-2024-50183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: amd_sfh: Switch to device-managed dmam_alloc_coherent()\n\nUsing the device-managed version allows to simplify clean-up in probe()\nerror path.\n\nAdditionally, this device-managed ensures proper cleanup, which helps to\nresolve memory errors, page faults, btrfs going read-only, and btrfs\ndisk corruption.(CVE-2024-50189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfork: do not invoke uffd on fork if error occurs\n\nPatch series \u0026quot;fork: do not expose incomplete mm on fork\u0026quot;.\n\nDuring fork we may place the virtual memory address space into an\ninconsistent state before the fork operation is complete.\n\nIn addition, we may encounter an error during the fork operation that\nindicates that the virtual memory address space is invalidated.\n\nAs a result, we should not be exposing it in any way to external machinery\nthat might interact with the mm or VMAs, machinery that is not designed to\ndeal with incomplete state.\n\nWe specifically update the fork logic to defer khugepaged and ksm to the\nend of the operation and only to be invoked if no error arose, and\ndisallow uffd from observing fork events should an error have occurred.\n\n\nThis patch (of 2):\n\nCurrently on fork we expose the virtual address space of a process to\nuserland unconditionally if uffd is registered in VMAs, regardless of\nwhether an error arose in the fork.\n\nThis is performed in dup_userfaultfd_complete() which is invoked\nunconditionally, and performs two duties - invoking registered handlers\nfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing down\nuserfaultfd_fork_ctx objects established in dup_userfaultfd().\n\nThis is problematic, because the virtual address space may not yet be\ncorrectly initialised if an error arose.\n\nThe change in commit d24062914837 (\u0026quot;fork: use __mt_dup() to duplicate\nmaple tree in dup_mmap()\u0026quot;) makes this more pertinent as we may be in a\nstate where entries in the maple tree are not yet consistent.\n\nWe address this by, on fork error, ensuring that we roll back state that\nwe would otherwise expect to clean up through the event being handled by\nuserland and perform the memory freeing duty otherwise performed by\ndup_userfaultfd_complete().\n\nWe do this by implementing a new function, dup_userfaultfd_fail(), which\nperforms the same loop, only decrementing reference counts.\n\nNote that we perform mmgrab() on the parent and child mm\u0026apos;s, however\nuserfaultfd_ctx_put() will mmdrop() this once the reference count drops to\nzero, so we will avoid memory leaks correctly here.(CVE-2024-50220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Vangogh: Fix kernel memory out of bounds write\n\nKASAN reports that the GPU metrics table allocated in\nvangogh_tables_init() is not large enough for the memset done in\nsmu_cmn_init_soft_gpu_metrics(). Condensed report follows:\n\n[   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]\n[   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067\n...\n[   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544\n[   33.861816] Tainted: [W]=WARN\n[   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023\n[   33.861822] Call Trace:\n[   33.861826]  \u0026lt;TASK\u0026gt;\n[   33.861829]  dump_stack_lvl+0x66/0x90\n[   33.861838]  print_report+0xce/0x620\n[   33.861853]  kasan_report+0xda/0x110\n[   33.862794]  kasan_check_range+0xfd/0x1a0\n[   33.862799]  __asan_memset+0x23/0x40\n[   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.867135]  dev_attr_show+0x43/0xc0\n[   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0\n[   33.867155]  seq_read_iter+0x3f8/0x1140\n[   33.867173]  vfs_read+0x76c/0xc50\n[   33.867198]  ksys_read+0xfb/0x1d0\n[   33.867214]  do_syscall_64+0x90/0x160\n...\n[   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:\n[   33.867358]  kasan_save_stack+0x33/0x50\n[   33.867364]  kasan_save_track+0x17/0x60\n[   33.867367]  __kasan_kmalloc+0x87/0x90\n[   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]\n[   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]\n[   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]\n[   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]\n[   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]\n[   33.869608]  local_pci_probe+0xda/0x180\n[   33.869614]  pci_device_probe+0x43f/0x6b0\n\nEmpirically we can confirm that the former allocates 152 bytes for the\ntable, while the latter memsets the 168 large block.\n\nRoot cause appears that when GPU metrics tables for v2_4 parts were added\nit was not considered to enlarge the table to fit.\n\nThe fix in this patch is rather \u0026quot;brute force\u0026quot; and perhaps later should be\ndone in a smarter way, by extracting and consolidating the part version to\nsize logic to a common helper, instead of brute forcing the largest\npossible allocation. Nevertheless, for now this works and fixes the out of\nbounds write.\n\nv2:\n * Drop impossible v3_0 case. (Mario)\n\n(cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)(CVE-2024-50221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()\n\nmodprobe iio-test-gts and rmmod it, then the following memory leak\noccurs:\n\n\tunreferenced object 0xffffff80c810be00 (size 64):\n\t  comm \u0026quot;kunit_try_catch\u0026quot;, pid 1654, jiffies 4294913981\n\t  hex dump (first 32 bytes):\n\t    02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00  ........ ...@...\n\t    80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00  ................\n\t  backtrace (crc a63d875e):\n\t    [\u0026lt;0000000028c1b3c2\u0026gt;] kmemleak_alloc+0x34/0x40\n\t    [\u0026lt;000000001d6ecc87\u0026gt;] __kmalloc_noprof+0x2bc/0x3c0\n\t    [\u0026lt;00000000393795c1\u0026gt;] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t    [\u0026lt;0000000071bb4b09\u0026gt;] 0xffffffdf052a62e0\n\t    [\u0026lt;000000000315bc18\u0026gt;] 0xffffffdf052a6488\n\t    [\u0026lt;00000000f9dc55b5\u0026gt;] kunit_try_run_case+0x13c/0x3ac\n\t    [\u0026lt;00000000175a3fd4\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t    [\u0026lt;00000000f505065d\u0026gt;] kthread+0x2e8/0x374\n\t    [\u0026lt;00000000bbfb0e5d\u0026gt;] ret_from_fork+0x10/0x20\n\tunreferenced object 0xffffff80cbfe9e70 (size 16):\n\t  comm \u0026quot;kunit_try_catch\u0026quot;, pid 1658, jiffies 4294914015\n\t  hex dump (first 16 bytes):\n\t    10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00  ....@...........\n\t  backtrace (crc 857f0cb4):\n\t    [\u0026lt;0000000028c1b3c2\u0026gt;] kmemleak_alloc+0x34/0x40\n\t    [\u0026lt;000000001d6ecc87\u0026gt;] __kmalloc_noprof+0x2bc/0x3c0\n\t    [\u0026lt;00000000393795c1\u0026gt;] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t    [\u0026lt;0000000071bb4b09\u0026gt;] 0xffffffdf052a62e0\n\t    [\u0026lt;000000007d089d45\u0026gt;] 0xffffffdf052a6864\n\t    [\u0026lt;00000000f9dc55b5\u0026gt;] kunit_try_run_case+0x13c/0x3ac\n\t    [\u0026lt;00000000175a3fd4\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t    [\u0026lt;00000000f505065d\u0026gt;] kthread+0x2e8/0x374\n\t    [\u0026lt;00000000bbfb0e5d\u0026gt;] ret_from_fork+0x10/0x20\n\t......\n\nIt includes 5*5 times \u0026quot;size 64\u0026quot; memory leaks, which correspond to 5 times\ntest_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))\nand gts_test_itimes size 5. It also includes 5*1 times \u0026quot;size 16\u0026quot;\nmemory leak, which correspond to one time __test_init_iio_gain_scale()\ncall with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes\nsize 5.\n\nThe reason is that the per_time_gains[i] is not freed which is allocated in\nthe \u0026quot;gts-\u0026gt;num_itime\u0026quot; for loop in iio_gts_build_avail_scale_table().(CVE-2024-50231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()\n\nIn the ad7124_write_raw() function, parameter val can potentially\nbe zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()\nis called within ad7124_set_channel_odr(). The ad7124_write_raw()\nfunction is invoked through the sequence: iio_write_channel_raw() -\u0026gt;\niio_write_channel_attribute() -\u0026gt; iio_channel_write(), with no checks\nin place to ensure val is non-zero.(CVE-2024-50232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom: qmp-usb: fix NULL-deref on runtime suspend\n\nCommit 413db06c05e7 (\u0026quot;phy: qcom-qmp-usb: clean up probe initialisation\u0026quot;)\nremoved most users of the platform device driver data, but mistakenly\nalso removed the initialisation despite the data still being used in the\nruntime PM callbacks.\n\nRestore the driver data initialisation at probe to avoid a NULL-pointer\ndereference on runtime suspend.\n\nApparently no one uses runtime PM, which currently needs to be enabled\nmanually through sysfs, with this driver.(CVE-2024-50240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address\n\nThe device stores IPv6 addresses that are used for encapsulation in\nlinear memory that is managed by the driver.\n\nChanging the remote address of an ip6gre net device never worked\nproperly, but since cited commit the following reproducer [1] would\nresult in a warning [2] and a memory leak [3]. The problem is that the\nnew remote address is never added by the driver to its hash table (and\ntherefore the device) and the old address is never removed from it.\n\nFix by programming the new address when the configuration of the ip6gre\nnet device changes and removing the old one. If the address did not\nchange, then the above would result in increasing the reference count of\nthe address and then decreasing it.\n\n[1]\n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit\n # ip link set dev bla type ip6gre remote 2001:db8:3::1\n # ip link del dev bla\n # devlink dev reload pci/0000:01:00.0\n\n[2]\nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0\nModules linked in:\nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_router_netdevice_event+0x55f/0x1240\n notifier_call_chain+0x5a/0xd0\n call_netdevice_notifiers_info+0x39/0x90\n unregister_netdevice_many_notify+0x63e/0x9d0\n rtnl_dellink+0x16b/0x3a0\n rtnetlink_rcv_msg+0x142/0x3f0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x242/0x390\n netlink_sendmsg+0x1de/0x420\n ____sys_sendmsg+0x2bd/0x320\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xd0\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[3]\nunreferenced object 0xffff898081f597a0 (size 32):\n  comm \u0026quot;ip\u0026quot;, pid 1626, jiffies 4294719324\n  hex dump (first 32 bytes):\n    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............\n    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............\n  backtrace (crc fd9be911):\n    [\u0026lt;00000000df89c55d\u0026gt;] __kmalloc_cache_noprof+0x1da/0x260\n    [\u0026lt;00000000ff2a1ddb\u0026gt;] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340\n    [\u0026lt;000000009ddd445d\u0026gt;] mlxsw_sp_router_netdevice_event+0x47b/0x1240\n    [\u0026lt;00000000743e7757\u0026gt;] notifier_call_chain+0x5a/0xd0\n    [\u0026lt;000000007c7b9e13\u0026gt;] call_netdevice_notifiers_info+0x39/0x90\n    [\u0026lt;000000002509645d\u0026gt;] register_netdevice+0x5f7/0x7a0\n    [\u0026lt;00000000c2e7d2a9\u0026gt;] ip6gre_newlink_common.isra.0+0x65/0x130\n    [\u0026lt;0000000087cd6d8d\u0026gt;] ip6gre_newlink+0x72/0x120\n    [\u0026lt;000000004df7c7cc\u0026gt;] rtnl_newlink+0x471/0xa20\n    [\u0026lt;0000000057ed632a\u0026gt;] rtnetlink_rcv_msg+0x142/0x3f0\n    [\u0026lt;0000000032e0d5b5\u0026gt;] netlink_rcv_skb+0x50/0x100\n    [\u0026lt;00000000908bca63\u0026gt;] netlink_unicast+0x242/0x390\n    [\u0026lt;00000000cdbe1c87\u0026gt;] netlink_sendmsg+0x1de/0x420\n    [\u0026lt;0000000011db153e\u0026gt;] ____sys_sendmsg+0x2bd/0x320\n    [\u0026lt;000000003b6d53eb\u0026gt;] ___sys_sendmsg+0x9a/0xe0\n    [\u0026lt;00000000cae27c62\u0026gt;] __sys_sendmsg+0x7a/0xd0(CVE-2024-50252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()\n\nI got a syzbot report without a repro [1] crashing in nf_send_reset6()\n\nI think the issue is that dev-\u0026gt;hard_header_len is zero, and we attempt\nlater to push an Ethernet header.\n\nUse LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.\n\n[1]\n\nskbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900045269b0 EFLAGS: 00010282\nRAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800\nRDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000\nRBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc\nR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140\nR13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c\nFS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_push+0xe5/0x100 net/core/skbuff.c:2636\n  eth_header+0x38/0x1f0 net/ethernet/eth.c:83\n  dev_hard_header include/linux/netdevice.h:3208 [inline]\n  nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358\n  nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48\n  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288\n  nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK include/linux/netfilter.h:312 [inline]\n  br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]\n  br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424\n  __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562\n  __netif_receive_skb_one_core net/core/dev.c:5666 [inline]\n  __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781\n  netif_receive_skb_internal net/core/dev.c:5867 [inline]\n  netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926\n  tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550\n  tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007\n  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053\n  new_sync_write fs/read_write.c:590 [inline]\n  vfs_write+0xa6d/0xc90 fs/read_write.c:683\n  ksys_write+0x183/0x2b0 fs/read_write.c:736\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fdbeeb7d1ff\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48\nRSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff\nRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8\nRBP: 00007fdbeebf12be R08: 0000000\n---truncated---(CVE-2024-50256)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: arc: fix the device for dma_map_single/dma_unmap_single\n\nThe ndev-\u0026gt;dev and pdev-\u0026gt;dev aren\u0026apos;t the same device, use ndev-\u0026gt;dev.parent\nwhich has dma_mask, ndev-\u0026gt;dev.parent is just pdev-\u0026gt;dev.\nOr it would cause the following issue:\n\n[   39.933526] ------------[ cut here ]------------\n[   39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8(CVE-2024-50295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when uninstalling driver\n\nWhen the driver is uninstalled and the VF is disabled concurrently, a\nkernel crash occurs. The reason is that the two actions call function\npci_disable_sriov(). The num_VFs is checked to determine whether to\nrelease the corresponding resources. During the second calling, num_VFs\nis not 0 and the resource release function is called. However, the\ncorresponding resource has been released during the first invoking.\nTherefore, the problem occurs:\n\n[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n...\n[15278.131557][T50670] Call trace:\n[15278.134686][T50670]  klist_put+0x28/0x12c\n[15278.138682][T50670]  klist_del+0x14/0x20\n[15278.142592][T50670]  device_del+0xbc/0x3c0\n[15278.146676][T50670]  pci_remove_bus_device+0x84/0x120\n[15278.151714][T50670]  pci_stop_and_remove_bus_device+0x6c/0x80\n[15278.157447][T50670]  pci_iov_remove_virtfn+0xb4/0x12c\n[15278.162485][T50670]  sriov_disable+0x50/0x11c\n[15278.166829][T50670]  pci_disable_sriov+0x24/0x30\n[15278.171433][T50670]  hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]\n[15278.178039][T50670]  hclge_exit+0x28/0xd0 [hclge]\n[15278.182730][T50670]  __se_sys_delete_module.isra.0+0x164/0x230\n[15278.188550][T50670]  __arm64_sys_delete_module+0x1c/0x30\n[15278.193848][T50670]  invoke_syscall+0x50/0x11c\n[15278.198278][T50670]  el0_svc_common.constprop.0+0x158/0x164\n[15278.203837][T50670]  do_el0_svc+0x34/0xcc\n[15278.207834][T50670]  el0_svc+0x20/0x30\n\nFor details, see the following figure.\n\n     rmmod hclge              disable VFs\n----------------------------------------------------\nhclge_exit()            sriov_numvfs_store()\n  ...                     device_lock()\n  pci_disable_sriov()     hns3_pci_sriov_configure()\n                            pci_disable_sriov()\n                              sriov_disable()\n    sriov_disable()             if !num_VFs :\n      if !num_VFs :               return;\n        return;                 sriov_del_vfs()\n      sriov_del_vfs()             ...\n        ...                       klist_put()\n        klist_put()               ...\n        ...                     num_VFs = 0;\n      num_VFs = 0;        device_unlock();\n\nIn this patch, when driver is removing, we get the device_lock()\nto protect num_VFs, just like sriov_numvfs_store().(CVE-2024-50296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()\n\nThe per-netns IP tunnel hash table is protected by the RTNL mutex and\nip_tunnel_find() is only called from the control path where the mutex is\ntaken.\n\nAdd a lockdep expression to hlist_for_each_entry_rcu() in\nip_tunnel_find() in order to validate that the mutex is held and to\nsilence the suspicious RCU usage warning [1].\n\n[1]\nWARNING: suspicious RCU usage\n6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted\n-----------------------------\nnet/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by ip/362:\n #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60\n\nstack backtrace:\nCPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n lockdep_rcu_suspicious.cold+0x4f/0xd6\n ip_tunnel_find+0x435/0x4d0\n ip_tunnel_newlink+0x517/0x7a0\n ipgre_newlink+0x14c/0x170\n __rtnl_newlink+0x1173/0x19c0\n rtnl_newlink+0x6c/0xa0\n rtnetlink_rcv_msg+0x3cc/0xf60\n netlink_rcv_skb+0x171/0x450\n netlink_unicast+0x539/0x7f0\n netlink_sendmsg+0x8c1/0xd80\n ____sys_sendmsg+0x8f9/0xc20\n ___sys_sendmsg+0x197/0x1e0\n __sys_sendmsg+0x122/0x1f0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-50304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in intel_hdcp_get_capability\n\nSometimes during hotplug scenario or suspend/resume scenario encoder is\nnot always initialized when intel_hdcp_get_capability add\na check to avoid kernel null pointer dereference.(CVE-2024-53051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\n\nIn case the non-paged data of a SKB carries protocol header and protocol\npayload to be transmitted on a certain platform that the DMA AXI address\nwidth is configured to 40-bit/48-bit, or the size of the non-paged data\nis bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI\naddress width is configured to 32-bit, then this SKB requires at least\ntwo DMA transmit descriptors to serve it.\n\nFor example, three descriptors are allocated to split one DMA buffer\nmapped from one piece of non-paged data:\n    dma_desc[N + 0],\n    dma_desc[N + 1],\n    dma_desc[N + 2].\nThen three elements of tx_q-\u0026gt;tx_skbuff_dma[] will be allocated to hold\nextra information to be reused in stmmac_tx_clean():\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0],\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1],\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].\nNow we focus on tx_q-\u0026gt;tx_skbuff_dma[entry].buf, which is the DMA buffer\naddress returned by DMA mapping call. stmmac_tx_clean() will try to\nunmap the DMA buffer _ONLY_IF_ tx_q-\u0026gt;tx_skbuff_dma[entry].buf\nis a valid buffer address.\n\nThe expected behavior that saves DMA buffer address of this non-paged\ndata to tx_q-\u0026gt;tx_skbuff_dma[entry].buf is:\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].buf = dma_map_single();\nUnfortunately, the current code misbehaves like this:\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf = dma_map_single();\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].buf = NULL;\n\nOn the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the\nDMA engine, tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf is a valid buffer address\nobviously, then the DMA buffer will be unmapped immediately.\nThere may be a rare case that the DMA engine does not finish the\npending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go\nhorribly wrong, DMA is going to access a unmapped/unreferenced memory\nregion, corrupted data will be transmited or iommu fault will be\ntriggered :(\n\nIn contrast, the for-loop that maps SKB fragments behaves perfectly\nas expected, and that is how the driver should do for both non-paged\ndata and paged frags actually.\n\nThis patch corrects DMA map/unmap sequences by fixing the array index\nfor tx_q-\u0026gt;tx_skbuff_dma[entry].buf when assigning DMA buffer address.\n\nTested and verified on DWXGMAC CORE 3.20a(CVE-2024-53058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx\n\nAs the introduction of the support for vsock and unix sockets in sockmap,\ntls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.\nvsock and af_unix sockets have vsock_sock and unix_sock instead of\ninet_connection_sock. For these sockets, tls_get_ctx may return an invalid\npointer and cause page fault in function tls_sw_ctx_rx.\n\nBUG: unable to handle page fault for address: 0000000000040030\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:sk_psock_strp_data_ready+0x23/0x60\nCall Trace:\n ? __die+0x81/0xc3\n ? no_context+0x194/0x350\n ? do_page_fault+0x30/0x110\n ? async_page_fault+0x3e/0x50\n ? sk_psock_strp_data_ready+0x23/0x60\n virtio_transport_recv_pkt+0x750/0x800\n ? update_load_avg+0x7e/0x620\n vsock_loopback_work+0xd0/0x100\n process_one_work+0x1a7/0x360\n worker_thread+0x30/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x112/0x130\n ? __kthread_cancel_work+0x40/0x40\n ret_from_fork+0x1f/0x40\n\nv2:\n  - Add IS_ICSK check\nv3:\n  - Update the commits in Fixes(CVE-2024-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: defer partition scanning\n\nWe need to suppress the partition scan from occuring within the\ncontroller\u0026apos;s scan_work context. If a path error occurs here, the IO will\nwait until a path becomes available or all paths are torn down, but that\naction also occurs within scan_work, so it would deadlock. Defer the\npartion scan to a different context that does not block scan_work.(CVE-2024-53093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES\n\nWhile running ISER over SIW, the initiator machine encounters a warning\nfrom skb_splice_from_iter() indicating that a slab page is being used in\nsend_page. To address this, it is better to add a sendpage_ok() check\nwithin the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag\nshould be disabled before entering the network stack.\n\nA similar issue has been discussed for NVMe in this thread:\nhttps://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/\n\n  WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320\n  Call Trace:\n   tcp_sendmsg_locked+0x368/0xe40\n   siw_tx_hdt+0x695/0xa40 [siw]\n   siw_qp_sq_process+0x102/0xb00 [siw]\n   siw_sq_resume+0x39/0x110 [siw]\n   siw_run_sq+0x74/0x160 [siw]\n   kthread+0xd2/0x100\n   ret_from_fork+0x34/0x40\n   ret_from_fork_asm+0x1a/0x30(CVE-2024-53094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: krealloc: Fix MTE false alarm in __do_krealloc\n\nThis patch addresses an issue introduced by commit 1a83a716ec233 (\u0026quot;mm:\nkrealloc: consider spare memory for __GFP_ZERO\u0026quot;) which causes MTE\n(Memory Tagging Extension) to falsely report a slab-out-of-bounds error.\n\nThe problem occurs when zeroing out spare memory in __do_krealloc. The\noriginal code only considered software-based KASAN and did not account\nfor MTE. It does not reset the KASAN tag before calling memset, leading\nto a mismatch between the pointer tag and the memory tag, resulting\nin a false positive.\n\nExample of the error:\n==================================================================\nswapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188\nswapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1\nswapper/0: Pointer tag: [f4], memory tag: [fe]\nswapper/0:\nswapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.\nswapper/0: Hardware name: MT6991(ENG) (DT)\nswapper/0: Call trace:\nswapper/0:  dump_backtrace+0xfc/0x17c\nswapper/0:  show_stack+0x18/0x28\nswapper/0:  dump_stack_lvl+0x40/0xa0\nswapper/0:  print_report+0x1b8/0x71c\nswapper/0:  kasan_report+0xec/0x14c\nswapper/0:  __do_kernel_fault+0x60/0x29c\nswapper/0:  do_bad_area+0x30/0xdc\nswapper/0:  do_tag_check_fault+0x20/0x34\nswapper/0:  do_mem_abort+0x58/0x104\nswapper/0:  el1_abort+0x3c/0x5c\nswapper/0:  el1h_64_sync_handler+0x80/0xcc\nswapper/0:  el1h_64_sync+0x68/0x6c\nswapper/0:  __memset+0x84/0x188\nswapper/0:  btf_populate_kfunc_set+0x280/0x3d8\nswapper/0:  __register_btf_kfunc_id_set+0x43c/0x468\nswapper/0:  register_btf_kfunc_id_set+0x48/0x60\nswapper/0:  register_nf_nat_bpf+0x1c/0x40\nswapper/0:  nf_nat_init+0xc0/0x128\nswapper/0:  do_one_initcall+0x184/0x464\nswapper/0:  do_initcall_level+0xdc/0x1b0\nswapper/0:  do_initcalls+0x70/0xc0\nswapper/0:  do_basic_setup+0x1c/0x28\nswapper/0:  kernel_init_freeable+0x144/0x1b8\nswapper/0:  kernel_init+0x20/0x1a8\nswapper/0:  ret_from_fork+0x10/0x20\n==================================================================(CVE-2024-53097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: tcp: avoid race between queue_lock lock and destroy\n\nCommit 76d54bf20cdc (\u0026quot;nvme-tcp: don\u0026apos;t access released socket during\nerror recovery\u0026quot;) added a mutex_lock() call for the queue-\u0026gt;queue_lock\nin nvme_tcp_get_address(). However, the mutex_lock() races with\nmutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.\n\nDEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\nWARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220\nModules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd 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 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]\nCPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:__mutex_lock+0xcf0/0x1220\nCode: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd \u0026lt;0f\u0026gt; 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1\nRSP: 0018:ffff88811305f760 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001\nRBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341\nR10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058\nFS:  00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn.cold+0x5b/0x1af\n ? __mutex_lock+0xcf0/0x1220\n ? report_bug+0x1ec/0x390\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x13/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? __mutex_lock+0xcf0/0x1220\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0xd6a/0x59e0\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]\n nvme_sysfs_show_address+0x81/0xc0 [nvme_core]\n dev_attr_show+0x42/0x80\n ? __asan_memset+0x1f/0x40\n sysfs_kf_seq_show+0x1f0/0x370\n seq_read_iter+0x2cb/0x1130\n ? rw_verify_area+0x3b1/0x590\n ? __mutex_lock+0x433/0x1220\n vfs_read+0x6a6/0xa20\n ? lockdep_hardirqs_on+0x78/0x100\n ? __pfx_vfs_read+0x10/0x10\n ksys_read+0xf7/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n ? __x64_sys_openat+0x105/0x1d0\n do_syscall_64+0x93/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? __pfx_ksys_read+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? do_syscall_64+0x9f/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f9713f55cfa\nCode: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4\n---truncated---(CVE-2024-53100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: fix buffer overrun in ima_eventdigest_init_common\n\nFunction ima_eventdigest_init() calls ima_eventdigest_init_common()\nwith HASH_ALGO__LAST which is then used to access the array\nhash_digest_size[] leading to buffer overrun. Have a conditional\nstatement to handle this.(CVE-2024-53106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnommu: pass NULL argument to vma_iter_prealloc()\n\nWhen deleting a vma entry from a maple tree, it has to pass NULL to\nvma_iter_prealloc() in order to calculate internal state of the tree, but\nit passed a wrong argument.  As a result, nommu kernels crashed upon\naccessing a vma iterator, such as acct_collect() reading the size of vma\nentries after do_munmap().\n\nThis commit fixes this issue by passing a right argument to the\npreallocation call.(CVE-2024-53109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix NULL pointer dereference in alloc_pages_bulk_noprof\n\nWe triggered a NULL pointer dereference for ac.preferred_zoneref-\u0026gt;zone in\nalloc_pages_bulk_noprof() when the task is migrated between cpusets.\n\nWhen cpuset is enabled, in prepare_alloc_pages(), ac-\u0026gt;nodemask may be\n\u0026amp;current-\u0026gt;mems_allowed.  when first_zones_zonelist() is called to find\npreferred_zoneref, the ac-\u0026gt;nodemask may be modified concurrently if the\ntask is migrated between different cpusets.  Assuming we have 2 NUMA Node,\nwhen traversing Node1 in ac-\u0026gt;zonelist, the nodemask is 2, and when\ntraversing Node2 in ac-\u0026gt;zonelist, the nodemask is 1.  As a result, the\nac-\u0026gt;preferred_zoneref points to NULL zone.\n\nIn alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a\nallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading\nto NULL pointer dereference.\n\n__alloc_pages_noprof() fixes this issue by checking NULL pointer in commit\nea57485af8f4 (\u0026quot;mm, page_alloc: fix check for NULL preferred_zone\u0026quot;) and\ncommit df76cee6bbeb (\u0026quot;mm, page_alloc: remove redundant checks from alloc\nfastpath\u0026quot;).\n\nTo fix it, check NULL pointer for preferred_zoneref-\u0026gt;zone.(CVE-2024-53113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix accept_queue memory leak\n\nAs the final stages of socket destruction may be delayed, it is possible\nthat virtio_transport_recv_listen() will be called after the accept_queue\nhas been flushed, but before the SOCK_DONE flag has been set. As a result,\nsockets enqueued after the flush would remain unremoved, leading to a\nmemory leak.\n\nvsock_release\n  __vsock_release\n    lock\n    virtio_transport_release\n      virtio_transport_close\n        schedule_delayed_work(close_work)\n    sk_shutdown = SHUTDOWN_MASK\n(!) flush accept_queue\n    release\n                                        virtio_transport_recv_pkt\n                                          vsock_find_bound_socket\n                                          lock\n                                          if flag(SOCK_DONE) return\n                                          virtio_transport_recv_listen\n                                            child = vsock_create_connected\n                                      (!)   vsock_enqueue_accept(child)\n                                          release\nclose_work\n  lock\n  virtio_transport_do_close\n    set_flag(SOCK_DONE)\n    virtio_transport_remove_sock\n      vsock_remove_sock\n        vsock_remove_bound\n  release\n\nIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() during\nsocket destruction.\n\nunreferenced object 0xffff888109e3f800 (size 2040):\n  comm \u0026quot;kworker/5:2\u0026quot;, pid 371, jiffies 4294940105\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............\n  backtrace (crc 9e5f4e84):\n    [\u0026lt;ffffffff81418ff1\u0026gt;] kmem_cache_alloc_noprof+0x2c1/0x360\n    [\u0026lt;ffffffff81d27aa0\u0026gt;] sk_prot_alloc+0x30/0x120\n    [\u0026lt;ffffffff81d2b54c\u0026gt;] sk_alloc+0x2c/0x4b0\n    [\u0026lt;ffffffff81fe049a\u0026gt;] __vsock_create.constprop.0+0x2a/0x310\n    [\u0026lt;ffffffff81fe6d6c\u0026gt;] virtio_transport_recv_pkt+0x4dc/0x9a0\n    [\u0026lt;ffffffff81fe745d\u0026gt;] vsock_loopback_work+0xfd/0x140\n    [\u0026lt;ffffffff810fc6ac\u0026gt;] process_one_work+0x20c/0x570\n    [\u0026lt;ffffffff810fce3f\u0026gt;] worker_thread+0x1bf/0x3a0\n    [\u0026lt;ffffffff811070dd\u0026gt;] kthread+0xdd/0x110\n    [\u0026lt;ffffffff81044fdd\u0026gt;] ret_from_fork+0x2d/0x50\n    [\u0026lt;ffffffff8100785a\u0026gt;] ret_from_fork_asm+0x1a/0x30(CVE-2024-53119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: CT: Fix null-ptr-deref in add rule err flow\n\nIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()\ncallback returns error, zone_rule-\u0026gt;attr is used uninitiated. Fix it to\nuse attr which has the needed pointer value.\n\nKernel log:\n BUG: kernel NULL pointer dereference, address: 0000000000000110\n RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]\n\u2026\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x20/0x70\n  ? page_fault_oops+0x150/0x3e0\n  ? exc_page_fault+0x74/0x140\n  ? asm_exc_page_fault+0x22/0x30\n  ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]\n  ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]\n  mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]\n  ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]\n  nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]\n  flow_offload_work_handler+0x142/0x320 [nf_flow_table]\n  ? finish_task_switch.isra.0+0x15b/0x2b0\n  process_one_work+0x16c/0x320\n  worker_thread+0x28c/0x3a0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xb8/0xf0\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2d/0x50\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;(CVE-2024-53120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fs, lock FTE when checking if active\n\nThe referenced commits introduced a two-step process for deleting FTEs:\n\n- Lock the FTE, delete it from hardware, set the hardware deletion function\n  to NULL and unlock the FTE.\n- Lock the parent flow group, delete the software copy of the FTE, and\n  remove it from the xarray.\n\nHowever, this approach encounters a race condition if a rule with the same\nmatch value is added simultaneously. In this scenario, fs_core may set the\nhardware deletion function to NULL prematurely, causing a panic during\nsubsequent rule deletions.\n\nTo prevent this, ensure the active flag of the FTE is checked under a lock,\nwhich will prevent the fs_core layer from attaching a new steering rule to\nan FTE that is in the process of deletion.\n\n[  438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func\n[  438.968205] ------------[ cut here ]------------\n[  438.968654] refcount_t: decrement hit 0; leaking memory.\n[  438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110\n[  438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]\n[  438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8\n[  438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110\n[  438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90\n[  438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286\n[  438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000\n[  438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0\n[  438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0\n[  438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0\n[  438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0\n[  438.980607] FS:  00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000\n[  438.983984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0\n[  438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  438.986507] Call Trace:\n[  438.986799]  \u0026lt;TASK\u0026gt;\n[  438.987070]  ? __warn+0x7d/0x110\n[  438.987426]  ? refcount_warn_saturate+0xfb/0x110\n[  438.987877]  ? report_bug+0x17d/0x190\n[  438.988261]  ? prb_read_valid+0x17/0x20\n[  438.988659]  ? handle_bug+0x53/0x90\n[  438.989054]  ? exc_invalid_op+0x14/0x70\n[  438.989458]  ? asm_exc_invalid_op+0x16/0x20\n[  438.989883]  ? refcount_warn_saturate+0xfb/0x110\n[  438.990348]  mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]\n[  438.990932]  __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]\n[  438.991519]  ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]\n[  438.992054]  ? xas_load+0x9/0xb0\n[  438.992407]  mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]\n[  438.993037]  mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]\n[  438.993623]  mlx5e_flow_put+0x29/0x60 [mlx5_core]\n[  438.994161]  mlx5e_delete_flower+0x261/0x390 [mlx5_core]\n[  438.994728]  tc_setup_cb_destroy+0xb9/0x190\n[  438.995150]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n[  438.995650]  fl_change+0x11a4/0x13c0 [cls_flower]\n[  438.996105]  tc_new_tfilter+0x347/0xbc0\n[  438.996503]  ? __\n---truncated---(CVE-2024-53121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: cope racing subflow creation in mptcp_rcv_space_adjust\n\nAdditional active subflows - i.e. created by the in kernel path\nmanager - are included into the subflow list before starting the\n3whs.\n\nA racing recvmsg() spooling data received on an already established\nsubflow would unconditionally call tcp_cleanup_rbuf() on all the\ncurrent subflows, potentially hitting a divide by zero error on\nthe newly created ones.\n\nExplicitly check that the subflow is in a suitable state before\ninvoking tcp_cleanup_rbuf().(CVE-2024-53122)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: error out earlier on disconnect\n\nEric reported a division by zero splat in the MPTCP protocol:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted\n6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0\nHardware name: Google Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nRIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163\nCode: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8\n0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 \u0026lt;f7\u0026gt; 7c\n24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89\nRSP: 0018:ffffc900041f7930 EFLAGS: 00010293\nRAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b\nRDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004\nRBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67\nR10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80\nR13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000\nFS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493\nmptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]\nmptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289\ninet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885\nsock_recvmsg_nosec net/socket.c:1051 [inline]\nsock_recvmsg+0x1b2/0x250 net/socket.c:1073\n__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265\n__do_sys_recvfrom net/socket.c:2283 [inline]\n__se_sys_recvfrom net/socket.c:2279 [inline]\n__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7feb5d857559\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559\nRDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000\nR10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c\nR13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef\n\nand provided a nice reproducer.\n\nThe root cause is the current bad handling of racing disconnect.\nAfter the blamed commit below, sk_wait_data() can return (with\nerror) with the underlying socket disconnected and a zero rcv_mss.\n\nCatch the error and return without performing any additional\noperations on the current socket.(CVE-2024-53123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix data-races around sk-\u0026gt;sk_forward_alloc\n\nSyzkaller reported this warning:\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0\n Modules linked in:\n CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:inet_sock_destruct+0x1c5/0x1e0\n Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 \u0026lt;0f\u0026gt; 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00\n RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206\n RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007\n RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00\n RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007\n R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00\n R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78\n FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __warn+0x88/0x130\n  ? inet_sock_destruct+0x1c5/0x1e0\n  ? report_bug+0x18e/0x1a0\n  ? handle_bug+0x53/0x90\n  ? exc_invalid_op+0x18/0x70\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? inet_sock_destruct+0x1c5/0x1e0\n  __sk_destruct+0x2a/0x200\n  rcu_do_batch+0x1aa/0x530\n  ? rcu_do_batch+0x13b/0x530\n  rcu_core+0x159/0x2f0\n  handle_softirqs+0xd3/0x2b0\n  ? __pfx_smpboot_thread_fn+0x10/0x10\n  run_ksoftirqd+0x25/0x30\n  smpboot_thread_fn+0xdd/0x1d0\n  kthread+0xd3/0x100\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x34/0x50\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nIts possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()\nconcurrently when sk-\u0026gt;sk_state == TCP_LISTEN with sk-\u0026gt;sk_lock unlocked,\nwhich triggers a data-race around sk-\u0026gt;sk_forward_alloc:\ntcp_v6_rcv\n    tcp_v6_do_rcv\n        skb_clone_and_charge_r\n            sk_rmem_schedule\n                __sk_mem_schedule\n                    sk_forward_alloc_add()\n            skb_set_owner_r\n                sk_mem_charge\n                    sk_forward_alloc_add()\n        __kfree_skb\n            skb_release_all\n                skb_release_head_state\n                    sock_rfree\n                        sk_mem_uncharge\n                            sk_forward_alloc_add()\n                            sk_mem_reclaim\n                                // set local var reclaimable\n                                __sk_mem_reclaim\n                                    sk_forward_alloc_add()\n\nIn this syzkaller testcase, two threads call\ntcp_v6_do_rcv() with skb-\u0026gt;truesize=768, the sk_forward_alloc changes like\nthis:\n (cpu 1)             | (cpu 2)             | sk_forward_alloc\n ...                 | ...                 | 0\n __sk_mem_schedule() |                     | +4096 = 4096\n                     | __sk_mem_schedule() | +4096 = 8192\n sk_mem_charge()     |                     | -768  = 7424\n                     | sk_mem_charge()     | -768  = 6656\n ...                 |    ...              |\n sk_mem_uncharge()   |                     | +768  = 7424\n reclaimable=7424    |                     |\n                     | sk_mem_uncharge()   | +768  = 8192\n                     | reclaimable=8192    |\n __sk_mem_reclaim()  |                     | -4096 = 4096\n                     | __sk_mem_reclaim()  | -8192 = -4096 != 0\n\nThe skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when\nsk-\u0026gt;sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().\nFix the same issue in dccp_v6_do_rcv().(CVE-2024-53124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN\n\nHide KVM\u0026apos;s pt_mode module param behind CONFIG_BROKEN, i.e. disable support\nfor virtualizing Intel PT via guest/host mode unless BROKEN=y.  There are\nmyriad bugs in the implementation, some of which are fatal to the guest,\nand others which put the stability and health of the host at risk.\n\nFor guest fatalities, the most glaring issue is that KVM fails to ensure\ntracing is disabled, and *stays* disabled prior to VM-Enter, which is\nnecessary as hardware disallows loading (the guest\u0026apos;s) RTIT_CTL if tracing\nis enabled (enforced via a VMX consistency check).  Per the SDM:\n\n  If the logical processor is operating with Intel PT enabled (if\n  IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \u0026quot;load\n  IA32_RTIT_CTL\u0026quot; VM-entry control must be 0.\n\nOn the host side, KVM doesn\u0026apos;t validate the guest CPUID configuration\nprovided by userspace, and even worse, uses the guest configuration to\ndecide what MSRs to save/load at VM-Enter and VM-Exit.  E.g. configuring\nguest CPUID to enumerate more address ranges than are supported in hardware\nwill result in KVM trying to passthrough, save, and load non-existent MSRs,\nwhich generates a variety of WARNs, ToPA ERRORs in the host, a potential\ndeadlock, etc.(CVE-2024-53135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: kTLS, Fix incorrect page refcounting\n\nThe kTLS tx handling code is using a mix of get_page() and\npage_ref_inc() APIs to increment the page reference. But on the release\npath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.\n\nThis is an issue when using pages from large folios: the get_page()\nreferences are stored on the folio page while the page_ref_inc()\nreferences are stored directly in the given page. On release the folio\npage will be dereferenced too many times.\n\nThis was found while doing kTLS testing with sendfile() + ZC when the\nserved file was read from NFS on a kernel with NFS large folios support\n(commit 49b29a573da8 (\u0026quot;nfs: add support for large folios\u0026quot;)).(CVE-2024-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix possible UAF in sctp_v6_available()\n\nA lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints\nthat sctp_v6_available() is calling dev_get_by_index_rcu()\nand ipv6_chk_addr() without holding rcu.\n\n[1]\n =============================\n WARNING: suspicious RCU usage\n 6.12.0-rc5-virtme #1216 Tainted: G        W\n -----------------------------\n net/core/dev.c:876 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by sctp_hello/31495:\n #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp\n\nstack backtrace:\n CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216\n Tainted: [W]=WARN\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:123)\n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)\n dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))\n sctp_v6_available (net/sctp/ipv6.c:701) sctp\n sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp\n sctp_bind (net/sctp/socket.c:320) sctp\n inet6_bind_sk (net/ipv6/af_inet6.c:465)\n ? security_socket_bind (security/security.c:4581 (discriminator 1))\n __sys_bind (net/socket.c:1848 net/socket.c:1869)\n ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)\n ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))\n __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))\n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n RIP: 0033:0x7f59b934a1e7\n Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48\nAll code\n========\n   0:\t44 00 00             \tadd    %r8b,(%rax)\n   3:\t48 8b 15 39 8c 0c 00 \tmov    0xc8c39(%rip),%rdx        # 0xc8c43\n   a:\tf7 d8                \tneg    %eax\n   c:\t64 89 02             \tmov    %eax,%fs:(%rdx)\n   f:\tb8 ff ff ff ff       \tmov    $0xffffffff,%eax\n  14:\teb bd                \tjmp    0xffffffffffffffd3\n  16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1)\n  1d:\t00 00 00\n  20:\t0f 1f 00             \tnopl   (%rax)\n  23:\tb8 31 00 00 00       \tmov    $0x31,%eax\n  28:\t0f 05                \tsyscall\n  2a:*\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\t\t\u0026lt;-- trapping instruction\n  30:\t73 01                \tjae    0x33\n  32:\tc3                   \tret\n  33:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c43\n  3a:\tf7 d8                \tneg    %eax\n  3c:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  3f:\t48                   \trex.W\n\nCode starting with the faulting instruction\n===========================================\n   0:\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\n   6:\t73 01                \tjae    0x9\n   8:\tc3                   \tret\n   9:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c19\n  10:\tf7 d8                \tneg    %eax\n  12:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  15:\t48                   \trex.W\n RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031\n RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7\n RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005\n RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000\n R10: 00007f59b9253298 R11: 000000000000\n---truncated---(CVE-2024-53139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: terminate outstanding dump on socket close\n\nNetlink supports iterative dumping of data. It provides the families\nthe following ops:\n - start - (optional) kicks off the dumping process\n - dump  - actual dump helper, keeps getting called until it returns 0\n - done  - (optional) pairs with .start, can be used for cleanup\nThe whole process is asynchronous and the repeated calls to .dump\ndon\u0026apos;t actually happen in a tight loop, but rather are triggered\nin response to recvmsg() on the socket.\n\nThis gives the user full control over the dump, but also means that\nthe user can close the socket without getting to the end of the dump.\nTo make sure .start is always paired with .done we check if there\nis an ongoing dump before freeing the socket, and if so call .done.\n\nThe complication is that sockets can get freed from BH and .done\nis allowed to sleep. So we use a workqueue to defer the call, when\nneeded.\n\nUnfortunately this does not work correctly. What we defer is not\nthe cleanup but rather releasing a reference on the socket.\nWe have no guarantee that we own the last reference, if someone\nelse holds the socket they may release it in BH and we\u0026apos;re back\nto square one.\n\nThe whole dance, however, appears to be unnecessary. Only the user\ncan interact with dumps, so we can clean up when socket is closed.\nAnd close always happens in process context. Some async code may\nstill access the socket after close, queue notification skbs to it etc.\nbut no dumps can start, end or otherwise make progress.\n\nDelete the workqueue and flush the dump state directly from the release\nhandler. Note that further cleanup is possible in -next, for instance\nwe now always call .done before releasing the main module reference,\nso dump doesn\u0026apos;t have to take a reference of its own.(CVE-2024-53140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE\n\nThis aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4\n(\u0026quot;Bluetooth: Always request for user confirmation for Just Works\u0026quot;)\nalways request user confirmation with confirm_hint set since the\nlikes of bluetoothd have dedicated policy around JUST_WORKS method\n(e.g. main.conf:JustWorksRepairing).\n\nCVE: CVE-2024-8805(CVE-2024-53144)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: Fix potential integer overflow during physmem setup\n\nThis issue happens when the real map size is greater than LONG_MAX,\nwhich can be easily triggered on UML/i386.(CVE-2024-53145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix bfqq uaf in bfq_limit_depth()\n\nSet new allocated bfqq to bic or remove freed bfqq from bic are both\nprotected by bfqd-\u0026gt;lock, however bfq_limit_depth() is deferencing bfqq\nfrom bic without the lock, this can lead to UAF if the io_context is\nshared by multiple tasks.\n\nFor example, test bfq with io_uring can trigger following UAF in v6.6:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x47/0x80\n print_address_description.constprop.0+0x66/0x300\n print_report+0x3e/0x70\n kasan_report+0xb4/0xf0\n bfqq_group+0x15/0x50\n bfqq_request_over_limit+0x130/0x9a0\n bfq_limit_depth+0x1b5/0x480\n __blk_mq_alloc_requests+0x2b5/0xa00\n blk_mq_get_new_requests+0x11d/0x1d0\n blk_mq_submit_bio+0x286/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __block_write_full_folio+0x3d0/0x640\n writepage_cb+0x3b/0xc0\n write_cache_pages+0x254/0x6c0\n write_cache_pages+0x254/0x6c0\n do_writepages+0x192/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 808602:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n __kasan_slab_alloc+0x83/0x90\n kmem_cache_alloc_node+0x1b1/0x6d0\n bfq_get_queue+0x138/0xfa0\n bfq_get_bfqq_handle_split+0xe3/0x2c0\n bfq_init_rq+0x196/0xbb0\n bfq_insert_request.isra.0+0xb5/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_insert_request+0x15d/0x440\n blk_mq_submit_bio+0x8a4/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __blkdev_direct_IO_async+0x2dd/0x330\n blkdev_write_iter+0x39a/0x450\n io_write+0x22a/0x840\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFreed by task 808589:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_save_free_info+0x27/0x40\n __kasan_slab_free+0x126/0x1b0\n kmem_cache_free+0x10c/0x750\n bfq_put_queue+0x2dd/0x770\n __bfq_insert_request.isra.0+0x155/0x7a0\n bfq_insert_request.isra.0+0x122/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_dispatch_plug_list+0x528/0x7e0\n blk_mq_flush_plug_list.part.0+0xe5/0x590\n __blk_flush_plug+0x3b/0x90\n blk_finish_plug+0x40/0x60\n do_writepages+0x19d/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFix the problem by protecting bic_to_bfqq() with bfqd-\u0026gt;lock.(CVE-2024-53166)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix use-after-free of nreq in reqsk_timer_handler().\n\nThe cited commit replaced inet_csk_reqsk_queue_drop_and_put() with\n__inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler().\n\nThen, oreq should be passed to reqsk_put() instead of req; otherwise\nuse-after-free of nreq could happen when reqsk is migrated but the\nretry attempt failed (e.g. due to timeout).\n\nLet\u0026apos;s pass oreq to reqsk_put().(CVE-2024-53206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible deadlocks\n\nThis fixes possible deadlocks like the following caused by\nhci_cmd_sync_dequeue causing the destroy function to run:\n\n INFO: task kworker/u19:0:143 blocked for more than 120 seconds.\n       Tainted: G        W  O        6.8.0-2024-03-19-intel-next-iLS-24ww14 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u19:0   state:D stack:0     pid:143   tgid:143   ppid:2      flags:0x00004000\n Workqueue: hci0 hci_cmd_sync_work [bluetooth]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  __schedule+0x374/0xaf0\n  schedule+0x3c/0xf0\n  schedule_preempt_disabled+0x1c/0x30\n  __mutex_lock.constprop.0+0x3ef/0x7a0\n  __mutex_lock_slowpath+0x13/0x20\n  mutex_lock+0x3c/0x50\n  mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]\n  ? kfree+0x211/0x2a0\n  hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]\n  ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]\n  cmd_complete_rsp+0x26/0x80 [bluetooth]\n  mgmt_pending_foreach+0x4d/0x70 [bluetooth]\n  __mgmt_power_off+0x8d/0x180 [bluetooth]\n  ? _raw_spin_unlock_irq+0x23/0x40\n  hci_dev_close_sync+0x445/0x5b0 [bluetooth]\n  hci_set_powered_sync+0x149/0x250 [bluetooth]\n  set_powered_sync+0x24/0x60 [bluetooth]\n  hci_cmd_sync_work+0x90/0x150 [bluetooth]\n  process_one_work+0x13e/0x300\n  worker_thread+0x2f7/0x420\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0x107/0x140\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x3d/0x60\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1b/0x30\n  \u0026lt;/TASK\u0026gt;(CVE-2024-53207)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix receive ring space parameters when XDP is active\n\nThe MTU setting at the time an XDP multi-buffer is attached\ndetermines whether the aggregation ring will be used and the\nrx_skb_func handler.  This is done in bnxt_set_rx_skb_mode().\n\nIf the MTU is later changed, the aggregation ring setting may need\nto be changed and it may become out-of-sync with the settings\ninitially done in bnxt_set_rx_skb_mode().  This may result in\nrandom memory corruption and crashes as the HW may DMA data larger\nthan the allocated buffer size, such as:\n\nBUG: kernel NULL pointer dereference, address: 00000000000003c0\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S         OE      6.1.0-226bf9805506 #1\nHardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021\nRIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]\nCode: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 \u0026lt;0f\u0026gt; b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f\nRSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202\nRAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff\nRDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380\nRBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf\nR10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980\nR13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990\nFS:  0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]\n\nTo address the issue, we now call bnxt_set_rx_skb_mode() within\nbnxt_change_mtu() to properly set the AGG rings configuration and\nupdate rx_skb_func based on the new MTU value.\nAdditionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning of\nbnxt_set_rx_skb_mode() to make sure it gets set or cleared based on\nthe current MTU.(CVE-2024-53209)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs\n\nBase clocks are the first in being probed and are real dependencies of the\nrest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,\nRT305x and RT3883 \u0026apos;xtal\u0026apos; must be defined first since in any other case,\nwhen fixed clocks are probed they are delayed until \u0026apos;xtal\u0026apos; is probed so the\nfollowing warning appears:\n\n WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0\n Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000\n 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000\n 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000\n 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009\n 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000\n ...\n Call Trace:\n [\u0026lt;800065d0\u0026gt;] show_stack+0x64/0xf4\n [\u0026lt;804bca14\u0026gt;] dump_stack_lvl+0x38/0x60\n [\u0026lt;800218ac\u0026gt;] __warn+0x94/0xe4\n [\u0026lt;8002195c\u0026gt;] warn_slowpath_fmt+0x60/0x94\n [\u0026lt;80259ff8\u0026gt;] rt3883_bus_recalc_rate+0x98/0x138\n [\u0026lt;80254530\u0026gt;] __clk_register+0x568/0x688\n [\u0026lt;80254838\u0026gt;] of_clk_hw_register+0x18/0x2c\n [\u0026lt;8070b910\u0026gt;] rt2880_clk_of_clk_init_driver+0x18c/0x594\n [\u0026lt;8070b628\u0026gt;] of_clk_init+0x1c0/0x23c\n [\u0026lt;806fc448\u0026gt;] plat_time_init+0x58/0x18c\n [\u0026lt;806fdaf0\u0026gt;] time_init+0x10/0x6c\n [\u0026lt;806f9bc4\u0026gt;] start_kernel+0x458/0x67c\n\n ---[ end trace 0000000000000000 ]---\n\nWhen this driver was mainlined we could not find any active users of old\nralink SoCs so we cannot perform any real tests for them. Now, one user\nof a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and\nreported some issues in openWRT:\n- https://github.com/openwrt/openwrt/issues/16054\n\nThus, define a \u0026apos;rt2880_xtal_recalc_rate()\u0026apos; just returning the expected\nfrequency 40Mhz and use it along the old ralink SoCs to have a correct\nboot trace with no warnings and a working clock plan from the beggining.(CVE-2024-53223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix use-after-free in device_for_each_child()\n\nSyzbot has reported the following KASAN splat:\n\nBUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0\nRead of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980\n\nCPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x100/0x190\n ? device_for_each_child+0x18f/0x1a0\n print_report+0x13a/0x4cb\n ? __virt_addr_valid+0x5e/0x590\n ? __phys_addr+0xc6/0x150\n ? device_for_each_child+0x18f/0x1a0\n kasan_report+0xda/0x110\n ? device_for_each_child+0x18f/0x1a0\n ? __pfx_dev_memalloc_noio+0x10/0x10\n device_for_each_child+0x18f/0x1a0\n ? __pfx_device_for_each_child+0x10/0x10\n pm_runtime_set_memalloc_noio+0xf2/0x180\n netdev_unregister_kobject+0x1ed/0x270\n unregister_netdevice_many_notify+0x123c/0x1d80\n ? __mutex_trylock_common+0xde/0x250\n ? __pfx_unregister_netdevice_many_notify+0x10/0x10\n ? trace_contention_end+0xe6/0x140\n ? __mutex_lock+0x4e7/0x8f0\n ? __pfx_lock_acquire.part.0+0x10/0x10\n ? rcu_is_watching+0x12/0xc0\n ? unregister_netdev+0x12/0x30\n unregister_netdevice_queue+0x30d/0x3f0\n ? __pfx_unregister_netdevice_queue+0x10/0x10\n ? __pfx_down_write+0x10/0x10\n unregister_netdev+0x1c/0x30\n bnep_session+0x1fb3/0x2ab0\n ? __pfx_bnep_session+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_woken_wake_function+0x10/0x10\n ? __kthread_parkme+0x132/0x200\n ? __pfx_bnep_session+0x10/0x10\n ? kthread+0x13a/0x370\n ? __pfx_bnep_session+0x10/0x10\n kthread+0x2b7/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x48/0x80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4974:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_noprof+0x1d1/0x440\n hci_alloc_dev_priv+0x1d/0x2820\n __vhci_create_device+0xef/0x7d0\n vhci_write+0x2c7/0x480\n vfs_write+0x6a0/0xfc0\n ksys_write+0x12f/0x260\n do_syscall_64+0xc7/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 4979:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x4f/0x70\n kfree+0x141/0x490\n hci_release_dev+0x4d9/0x600\n bt_host_release+0x6a/0xb0\n device_release+0xa4/0x240\n kobject_put+0x1ec/0x5a0\n put_device+0x1f/0x30\n vhci_release+0x81/0xf0\n __fput+0x3f6/0xb30\n task_work_run+0x151/0x250\n do_exit+0xa79/0x2c30\n do_group_exit+0xd5/0x2a0\n get_signal+0x1fcd/0x2210\n arch_do_signal_or_restart+0x93/0x780\n syscall_exit_to_user_mode+0x140/0x290\n do_syscall_64+0xd4/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn \u0026apos;hci_conn_del_sysfs()\u0026apos;, \u0026apos;device_unregister()\u0026apos; may be called when\nan underlying (kobject) reference counter is greater than 1. This\nmeans that reparenting (happened when the device is actually freed)\nis delayed and, during that delay, parent controller device (hciX)\nmay be deleted. Since the latter may create a dangling pointer to\nfreed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()\n\nMove pm_runtime_set_active() to ivpu_pm_init() so when\nivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable()\nit already has correct runtime state, even if last resume was\nnot successful..(CVE-2024-54193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer\n\nThe AD7923 was updated to support devices with 8 channels, but the size\nof tx_buf and ring_xfer was not increased accordingly, leading to a\npotential buffer overflow in ad7923_update_scan_mode().(CVE-2024-56557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nad7780: fix division by zero in ad7780_write_raw()\n\nIn the ad7780_write_raw() , val2 can be zero, which might lead to a\ndivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()\nis based on iio_info\u0026apos;s write_raw. While val is explicitly declared that\ncan be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855]   ESR = 0x0000000096000004\n[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125]   SET = 0, FnV = 0\n[67840.878291]   EA = 0, S1PTW = 0\n[67840.881545]   FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456]  down_write+0x30/0x98\n[67841.096017]  start_creating.part.0+0x60/0x198\n[67841.100613]  debugfs_create_dir+0x48/0x1f8\n[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115]  full_proxy_write+0x68/0xc8\n[67841.129175]  vfs_write+0xd8/0x3f0\n[67841.132708]  ksys_write+0x70/0x108\n[67841.136317]  __arm64_sys_write+0x24/0x38\n[67841.140440]  invoke_syscall+0x50/0x128\n[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273]  do_el0_svc+0x24/0x38\n[67841.152773]  el0_svc+0x38/0xd8\n[67841.156009]  el0t_64_sync_handler+0xc0/0xc8\n[67841.160361]  el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Add cond_resched() for no forced preemption model\n\nFor no forced preemption model kernel, in the scenario where the\nexpander is connected to 12 high performance SAS SSDs, the following\ncall trace may occur:\n\n[  214.409199][  C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]\n[  214.568533][  C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)\n[  214.575224][  C240] pc : fput_many+0x8c/0xdc\n[  214.579480][  C240] lr : fput+0x1c/0xf0\n[  214.583302][  C240] sp : ffff80002de2b900\n[  214.587298][  C240] x29: ffff80002de2b900 x28: ffff1082aa412000\n[  214.593291][  C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000\n[  214.599284][  C240] x25: ffff1062bbac5c40 x24: 0000000000001000\n[  214.605277][  C240] x23: 000000000000000a x22: 0000000000000001\n[  214.611270][  C240] x21: 0000000000001000 x20: 0000000000000000\n[  214.617262][  C240] x19: ffff3062a41ae580 x18: 0000000000010000\n[  214.623255][  C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0\n[  214.629248][  C240] x15: ffffffffffffffff x14: 0000000003ffffff\n[  214.635241][  C240] x13: 000000000000ffff x12: 000000000000029c\n[  214.641234][  C240] x11: 0000000000000006 x10: ffff80003a9f7fd0\n[  214.647226][  C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001\n[  214.653219][  C240] x7 : 0000000000000002 x6 : 0000000000000080\n[  214.659212][  C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554\n[  214.665205][  C240] x3 : 0000000000000002 x2 : 0000000000000020\n[  214.671198][  C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8\n[  214.677191][  C240] Call trace:\n[  214.680320][  C240]  fput_many+0x8c/0xdc\n[  214.684230][  C240]  fput+0x1c/0xf0\n[  214.687707][  C240]  aio_complete_rw+0xd8/0x1fc\n[  214.692225][  C240]  blkdev_bio_end_io+0x98/0x140\n[  214.696917][  C240]  bio_endio+0x160/0x1bc\n[  214.701001][  C240]  blk_update_request+0x1c8/0x3bc\n[  214.705867][  C240]  scsi_end_request+0x3c/0x1f0\n[  214.710471][  C240]  scsi_io_completion+0x7c/0x1a0\n[  214.715249][  C240]  scsi_finish_command+0x104/0x140\n[  214.720200][  C240]  scsi_softirq_done+0x90/0x180\n[  214.724892][  C240]  blk_mq_complete_request+0x5c/0x70\n[  214.730016][  C240]  scsi_mq_done+0x48/0xac\n[  214.734194][  C240]  sas_scsi_task_done+0xbc/0x16c [libsas]\n[  214.739758][  C240]  slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]\n[  214.746185][  C240]  cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]\n[  214.752179][  C240]  irq_thread_fn+0x34/0xa4\n[  214.756435][  C240]  irq_thread+0xc4/0x130\n[  214.760520][  C240]  kthread+0x108/0x13c\n[  214.764430][  C240]  ret_from_fork+0x10/0x18\n\nThis is because in the hisi_sas driver, both the hardware interrupt\nhandler and the interrupt thread are executed on the same CPU. In the\nperformance test scenario, function irq_wait_for_interrupt() will always\nreturn 0 if lots of interrupts occurs and the CPU will be continuously\nconsumed. As a result, the CPU cannot run the watchdog thread. When the\nwatchdog time exceeds the specified time, call trace occurs.\n\nTo fix it, add cond_resched() to execute the watchdog thread.(CVE-2024-56589)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix not checking skb length on hci_acldata_packet\n\nThis fixes not checking if skb really contains an ACL header otherwise\nthe code may attempt to access some uninitilized/invalid memory past the\nvalid skb-\u0026gt;data.(CVE-2024-56590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix OOB map writes when deleting elements\n\nJordy says:\n\n\u0026quot;\nIn the xsk_map_delete_elem function an unsigned integer\n(map-\u0026gt;max_entries) is compared with a user-controlled signed integer\n(k). Due to implicit type conversion, a large unsigned value for\nmap-\u0026gt;max_entries can bypass the intended bounds check:\n\n\tif (k \u0026gt;= map-\u0026gt;max_entries)\n\t\treturn -EINVAL;\n\nThis allows k to hold a negative value (between -2147483648 and -2),\nwhich is then used as an array index in m-\u0026gt;xsk_map[k], which results\nin an out-of-bounds access.\n\n\tspin_lock_bh(\u0026amp;m-\u0026gt;lock);\n\tmap_entry = \u0026amp;m-\u0026gt;xsk_map[k]; // Out-of-bounds map_entry\n\told_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write\n\tif (old_xs)\n\t\txsk_map_sock_delete(old_xs, map_entry);\n\tspin_unlock_bh(\u0026amp;m-\u0026gt;lock);\n\nThe xchg operation can then be used to cause an out-of-bounds write.\nMoreover, the invalid map_entry passed to xsk_map_sock_delete can lead\nto further memory corruption.\n\u0026quot;\n\nIt indeed results in following splat:\n\n[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108\n[76612.904330] #PF: supervisor write access in kernel mode\n[76612.909639] #PF: error_code(0x0002) - not-present page\n[76612.914855] PGD 0 P4D 0\n[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP\n[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470\n[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60\n[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff \u0026lt;48\u0026gt; 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31\n[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246\n[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000\n[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000\n[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007\n[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8\n[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0\n[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000\n[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0\n[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[76613.041086] PKRU: 55555554\n[76613.043842] Call Trace:\n[76613.046331]  \u0026lt;TASK\u0026gt;\n[76613.048468]  ? __die+0x20/0x60\n[76613.051581]  ? page_fault_oops+0x15a/0x450\n[76613.055747]  ? search_extable+0x22/0x30\n[76613.059649]  ? search_bpf_extables+0x5f/0x80\n[76613.063988]  ? exc_page_fault+0xa9/0x140\n[76613.067975]  ? asm_exc_page_fault+0x22/0x30\n[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60\n[76613.076573]  ? xsk_map_delete_elem+0x23/0x60\n[76613.080914]  __sys_bpf+0x19b7/0x23c0\n[76613.084555]  __x64_sys_bpf+0x1a/0x20\n[76613.088194]  do_syscall_64+0x37/0xb0\n[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[76613.096962] RIP: 0033:0x7f80b6d1e88d\n[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48\n[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141\n[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d\n[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003\n[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000\n[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8\n[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00\n---truncated---(CVE-2024-56614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022]  ? __dentry_kill+0x121/0x170\n[596663.813030]  ? _cond_resched+0x15/0x30\n[596663.813034]  ? _cond_resched+0x15/0x30\n[596663.813039]  ? wait_for_completion+0x35/0x190\n[596663.813048]  ? try_to_wake_up+0x63/0x540\n[596663.813055]  free_task+0x5a/0x60\n[596663.813061]  kthread_stop+0xf3/0x100\n[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix LGR and link use-after-free issue\n\nWe encountered a LGR/link use-after-free issue, which manifested as\nthe LGR/link refcnt reaching 0 early and entering the clear process,\nmaking resource access unsafe.\n\n refcount_t: addition on 0; use-after-free.\n WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140\n Workqueue: events smc_lgr_terminate_work [smc]\n Call trace:\n  refcount_warn_saturate+0x9c/0x140\n  __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]\n  smc_lgr_terminate_work+0x28/0x30 [smc]\n  process_one_work+0x1b8/0x420\n  worker_thread+0x158/0x510\n  kthread+0x114/0x118\n\nor\n\n refcount_t: underflow; use-after-free.\n WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140\n Workqueue: smc_hs_wq smc_listen_work [smc]\n Call trace:\n  refcount_warn_saturate+0xf0/0x140\n  smcr_link_put+0x1cc/0x1d8 [smc]\n  smc_conn_free+0x110/0x1b0 [smc]\n  smc_conn_abort+0x50/0x60 [smc]\n  smc_listen_find_device+0x75c/0x790 [smc]\n  smc_listen_work+0x368/0x8a0 [smc]\n  process_one_work+0x1b8/0x420\n  worker_thread+0x158/0x510\n  kthread+0x114/0x118\n\nIt is caused by repeated release of LGR/link refcnt. One suspect is that\nsmc_conn_free() is called repeatedly because some smc_conn_free() from\nserver listening path are not protected by sock lock.\n\ne.g.\n\nCalls under socklock        | smc_listen_work\n-------------------------------------------------------\nlock_sock(sk)               | smc_conn_abort\nsmc_conn_free               | \\- smc_conn_free\n\\- smcr_link_put            |    \\- smcr_link_put (duplicated)\nrelease_sock(sk)\n\nSo here add sock lock protection in smc_listen_work() path, making it\nexclusive with other connection operations.(CVE-2024-56640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: initialize close_work early to avoid warning\n\nWe encountered a warning that close_work was canceled before\ninitialization.\n\n  WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0\n  Workqueue: events smc_lgr_terminate_work [smc]\n  RIP: 0010:__flush_work+0x19e/0x1b0\n  Call Trace:\n   ? __wake_up_common+0x7a/0x190\n   ? work_busy+0x80/0x80\n   __cancel_work_timer+0xe3/0x160\n   smc_close_cancel_work+0x1a/0x70 [smc]\n   smc_close_active_abort+0x207/0x360 [smc]\n   __smc_lgr_terminate.part.38+0xc8/0x180 [smc]\n   process_one_work+0x19e/0x340\n   worker_thread+0x30/0x370\n   ? process_one_work+0x340/0x340\n   kthread+0x117/0x130\n   ? __kthread_cancel_work+0x50/0x50\n   ret_from_fork+0x22/0x30\n\nThis is because when smc_close_cancel_work is triggered, e.g. the RDMA\ndriver is rmmod and the LGR is terminated, the conn-\u0026gt;close_work is\nflushed before initialization, resulting in WARN_ON(!work-\u0026gt;func).\n\n__smc_lgr_terminate             | smc_connect_{rdma|ism}\n-------------------------------------------------------------\n                                | smc_conn_create\n\t\t\t\t| \\- smc_lgr_register_conn\nfor conn in lgr-\u0026gt;conns_all      |\n\\- smc_conn_kill                |\n   \\- smc_close_active_abort    |\n      \\- smc_close_cancel_work  |\n         \\- cancel_work_sync    |\n            \\- __flush_work     |\n\t         (close_work)   |\n\t                        | smc_close_init\n\t                        | \\- INIT_WORK(\u0026amp;close_work)\n\nSo fix this by initializing close_work before establishing the\nconnection.(CVE-2024-56641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btmtk: avoid UAF in btmtk_process_coredump\n\nhci_devcd_append may lead to the release of the skb, so it cannot be\naccessed once it is called.\n\n==================================================================\nBUG: KASAN: slab-use-after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk]\nRead of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82\n\nCPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G     U             6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c\nHardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024\nWorkqueue: events btusb_rx_work [btusb]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xfd/0x150\n print_report+0x131/0x780\n kasan_report+0x177/0x1c0\n btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01]\n btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]\n btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 82:\n stack_trace_save+0xdc/0x190\n kasan_set_track+0x4e/0x80\n __kasan_slab_alloc+0x4e/0x60\n kmem_cache_alloc+0x19f/0x360\n skb_clone+0x132/0xf70\n btusb_recv_acl_mtk+0x104/0x1a0 [btusb]\n btusb_rx_work+0x9e/0xe0 [btusb]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n\nFreed by task 1733:\n stack_trace_save+0xdc/0x190\n kasan_set_track+0x4e/0x80\n kasan_save_free_info+0x28/0xb0\n ____kasan_slab_free+0xfd/0x170\n kmem_cache_free+0x183/0x3f0\n hci_devcd_rx+0x91a/0x2060 [bluetooth]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n\nThe buggy address belongs to the object at ffff888033cfab40\n which belongs to the cache skbuff_head_cache of size 232\nThe buggy address is located 112 bytes inside of\n freed 232-byte region [ffff888033cfab40, ffff888033cfac28)\n\nThe buggy address belongs to the physical page:\npage:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa\nhead:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0\nanon flags: 0x4000000000000840(slab|head|zone=1)\npage_type: 0xffffffff()\nraw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001\nraw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc\n ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb\n\u0026gt;ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                     ^\n ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc\n ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\n\nCheck if we need to call hci_devcd_complete before calling\nhci_devcd_append. That requires that we check data-\u0026gt;cd_info.cnt \u0026gt;=\nMTK_COREDUMP_NUM instead of data-\u0026gt;cd_info.cnt \u0026gt; MTK_COREDUMP_NUM, as we\nincrement data-\u0026gt;cd_info.cnt only once the call to hci_devcd_append\nsucceeds.(CVE-2024-56653)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()\n\nDuring early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,\nsince pageblock_order is still zero and it gets initialized\nlater during initmem_init() e.g.\nsetup_arch() -\u0026gt; initmem_init() -\u0026gt; sparse_init() -\u0026gt; set_pageblock_order()\n\nOne such use case where this causes issue is -\nearly_setup() -\u0026gt; early_init_devtree() -\u0026gt; fadump_reserve_mem() -\u0026gt; fadump_cma_init()\n\nThis causes CMA memory alignment check to be bypassed in\ncma_init_reserved_mem(). Then later cma_activate_area() can hit\na VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; order) - 1)) if the reserved memory\narea was not pageblock_order aligned.\n\nFix it by moving the fadump_cma_init() after initmem_init(),\nwhere other such cma reservations also gets called.\n\n\u0026lt;stack trace\u0026gt;\n==============\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010\nflags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA\nraw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000\nraw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; order) - 1))\n------------[ cut here ]------------\nkernel BUG at mm/page_alloc.c:778!\n\nCall Trace:\n__free_one_page+0x57c/0x7b0 (unreliable)\nfree_pcppages_bulk+0x1a8/0x2c8\nfree_unref_page_commit+0x3d4/0x4e4\nfree_unref_page+0x458/0x6d0\ninit_cma_reserved_pageblock+0x114/0x198\ncma_init_reserved_areas+0x270/0x3e0\ndo_one_initcall+0x80/0x2f8\nkernel_init_freeable+0x33c/0x530\nkernel_init+0x34/0x26c\nret_from_kernel_user_thread+0x14/0x1c(CVE-2024-56677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: musb: Fix hardware lockup on first Rx endpoint request\n\nThere is a possibility that a request\u0026apos;s callback could be invoked from\nusb_ep_queue() (call trace below, supplemented with missing calls):\n\nreq-\u0026gt;complete from usb_gadget_giveback_request\n\t(drivers/usb/gadget/udc/core.c:999)\nusb_gadget_giveback_request from musb_g_giveback\n\t(drivers/usb/musb/musb_gadget.c:147)\nmusb_g_giveback from rxstate\n\t(drivers/usb/musb/musb_gadget.c:784)\nrxstate from musb_ep_restart\n\t(drivers/usb/musb/musb_gadget.c:1169)\nmusb_ep_restart from musb_ep_restart_resume_work\n\t(drivers/usb/musb/musb_gadget.c:1176)\nmusb_ep_restart_resume_work from musb_queue_resume_work\n\t(drivers/usb/musb/musb_core.c:2279)\nmusb_queue_resume_work from musb_gadget_queue\n\t(drivers/usb/musb/musb_gadget.c:1241)\nmusb_gadget_queue from usb_ep_queue\n\t(drivers/usb/gadget/udc/core.c:300)\n\nAccording to the docstring of usb_ep_queue(), this should not happen:\n\n\u0026quot;Note that @req\u0026apos;s -\u0026gt;complete() callback must never be called from within\nusb_ep_queue() as that can create deadlock situations.\u0026quot;\n\nIn fact, a hardware lockup might occur in the following sequence:\n\n1. The gadget is initialized using musb_gadget_enable().\n2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an\n   interrupt.\n3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an\n   empty queue (next_request() returns NULL). The interrupt flag has\n   already been cleared by the glue layer handler, but the RXPKTRDY flag\n   remains set.\n4. The first request is enqueued using usb_ep_queue(), leading to the call\n   of req-\u0026gt;complete(), as shown in the call trace above.\n5. If the callback enables IRQs and another packet is waiting, step (3)\n   repeats. The request queue is empty because usb_g_giveback() removes the\n   request before invoking the callback.\n6. The endpoint remains locked up, as the interrupt triggered by hardware\n   setting the RXPKTRDY flag has been handled, but the flag itself remains\n   set.\n\nFor this scenario to occur, it is only necessary for IRQs to be enabled at\nsome point during the complete callback. This happens with the USB Ethernet\ngadget, whose rx_complete() callback calls netif_rx(). If called in the\ntask context, netif_rx() disables the bottom halves (BHs). When the BHs are\nre-enabled, IRQs are also enabled to allow soft IRQs to be processed. The\ngadget itself is initialized at module load (or at boot if built-in), but\nthe first request is enqueued when the network interface is brought up,\ntriggering rx_complete() in the task context via ioctl(). If a packet\narrives while the interface is down, it can prevent the interface from\nreceiving any further packets from the USB host.\n\nThe situation is quite complicated with many parties involved. This\nparticular issue can be resolved in several possible ways:\n\n1. Ensure that callbacks never enable IRQs. This would be difficult to\n   enforce, as discovering how netif_rx() interacts with interrupts was\n   already quite challenging and u_ether is not the only function driver.\n   Similar \u0026quot;bugs\u0026quot; could be hidden in other drivers as well.\n2. Disable MUSB interrupts in musb_g_giveback() before calling the callback\n   and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),\n   for example). This would ensure that MUSB interrupts are not handled\n   during the callback, even if IRQs are enabled. In fact, it would allow\n   IRQs to be enabled when releasing the lock. However, this feels like an\n   inelegant hack.\n3. Modify the interrupt handler to clear the RXPKTRDY flag if the request\n   queue is empty. While this approach also feels like a hack, it wastes\n   CPU time by attempting to handle incoming packets when the software is\n   not ready to process them.\n4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().\n   This ensures that the hardware can receive packets when there is at\n   least one request in the queue. Once I\n---truncated---(CVE-2024-56687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries: Fix dtl_access_lock to be a rw_semaphore\n\nThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because\nthe code calls kmalloc() while holding it, which can sleep:\n\n  # echo 1 \u0026gt; /proc/powerpc/vcpudispatch_stats\n  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh\n  preempt_count: 1, expected: 0\n  3 locks held by sh/199:\n   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438\n   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4\n   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4\n  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152\n  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries\n  Call Trace:\n    dump_stack_lvl+0x130/0x148 (unreliable)\n    __might_resched+0x174/0x410\n    kmem_cache_alloc_noprof+0x340/0x3d0\n    alloc_dtl_buffers+0x124/0x1ac\n    vcpudispatch_stats_write+0x2a8/0x5f4\n    proc_reg_write+0xf4/0x150\n    vfs_write+0xfc/0x438\n    ksys_write+0x88/0x148\n    system_call_exception+0x1c4/0x5a0\n    system_call_common+0xf4/0x258(CVE-2024-56701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: protect link down work from execute after lgr freed\n\nlink down work may be scheduled before lgr freed but execute\nafter lgr freed, which may result in crash. So it is need to\nhold a reference before shedule link down work, and put the\nreference after work executed or canceled.\n\nThe relevant crash call stack as follows:\n list_del corruption. prev-\u0026gt;next should be ffffb638c9c0fe20,\n    but was 0000000000000000\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:51!\n invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1\n Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014\n Workqueue: events smc_link_down_work [smc]\n RIP: 0010:__list_del_entry_valid.cold+0x31/0x47\n RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086\n RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000\n RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80\n RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38\n R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002\n R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0\n FS:  0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  rwsem_down_write_slowpath+0x17e/0x470\n  smc_link_down_work+0x3c/0x60 [smc]\n  process_one_work+0x1ac/0x350\n  worker_thread+0x49/0x2f0\n  ? rescuer_thread+0x360/0x360\n  kthread+0x118/0x140\n  ? __kthread_bind_mask+0x60/0x60\n  ret_from_fork+0x1f/0x30(CVE-2024-56718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Initialize cfid-\u0026gt;tcon before performing network ops\n\nAvoid leaking a tcon ref when a lease break races with opening the\ncached directory. Processing the leak break might take a reference to\nthe tcon in cached_dir_lease_break() and then fail to release the ref in\ncached_dir_offload_close, since cfid-\u0026gt;tcon is still NULL.(CVE-2024-56729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: check folio mapping after unlock in relocate_one_folio()\n\nWhen we call btrfs_read_folio() to bring a folio uptodate, we unlock the\nfolio. The result of that is that a different thread can modify the\nmapping (like remove it with invalidate) before we call folio_lock().\nThis results in an invalid page and we need to try again.\n\nIn particular, if we are relocating concurrently with aborting a\ntransaction, this can result in a crash like the following:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP\n  CPU: 76 PID: 1411631 Comm: kworker/u322:5\n  Workqueue: events_unbound btrfs_reclaim_bgs_work\n  RIP: 0010:set_page_extent_mapped+0x20/0xb0\n  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246\n  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000\n  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880\n  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0\n  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000\n  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff\n  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x78/0xc0\n  ? page_fault_oops+0x2a8/0x3a0\n  ? __switch_to+0x133/0x530\n  ? wq_worker_running+0xa/0x40\n  ? exc_page_fault+0x63/0x130\n  ? asm_exc_page_fault+0x22/0x30\n  ? set_page_extent_mapped+0x20/0xb0\n  relocate_file_extent_cluster+0x1a7/0x940\n  relocate_data_extent+0xaf/0x120\n  relocate_block_group+0x20f/0x480\n  btrfs_relocate_block_group+0x152/0x320\n  btrfs_relocate_chunk+0x3d/0x120\n  btrfs_reclaim_bgs_work+0x2ae/0x4e0\n  process_scheduled_works+0x184/0x370\n  worker_thread+0xc6/0x3e0\n  ? blk_add_timer+0xb0/0xb0\n  kthread+0xae/0xe0\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork+0x2f/0x40\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\n\nThis occurs because cleanup_one_transaction() calls\ndestroy_delalloc_inodes() which calls invalidate_inode_pages2() which\ntakes the folio_lock before setting mapping to NULL. We fail to check\nthis, and subsequently call set_extent_mapping(), which assumes that\nmapping != NULL (in fact it asserts that in debug mode)\n\nNote that the \u0026quot;fixes\u0026quot; patch here is not the one that introduced the\nrace (the very first iteration of this code from 2009) but a more recent\nchange that made this particular crash happen in practice..(CVE-2024-56758)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg\n\nSyzbot reports [1] an uninitialized value issue found by KMSAN in\ndib3000_read_reg().\n\nLocal u8 rb[2] is used in i2c_transfer() as a read buffer; in case\nthat call fails, the buffer may end up with some undefined values.\n\nSince no elaborate error handling is expected in dib3000_write_reg(),\nsimply zero out rb buffer to mitigate the problem.\n\n[1] Syzkaller report\ndvb-usb: bulk message failed: -22 (6/0)\n=====================================================\nBUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31\n dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290\n dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]\n dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]\n dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310\n dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110\n...\nLocal variable rb created at:\n dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54\n dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n...(CVE-2024-56769)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n                   NFS CLIENT\nthread1                             thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n  _nfs4_open_and_get_state\n   _nfs4_proc_open\n    nfs4_run_open_task\n     /* rpc_task1 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\n                                    umount -f\n                                    nfs_umount_begin\n                                     rpc_killall_tasks\n                                      rpc_signal_task\n     rpc_task1 been wakeup\n     and return -512\n _nfs4_do_open // while loop\n    ...\n    nfs4_run_open_task\n     /* rpc_task2 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n                    NFS SERVER\nnfsd1                  nfsd2       echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n  find_or_alloc_open_stateowner\n   // alloc oo1, stateid1\n                       nfsd4_open\n                        nfsd4_process_open1\n                        find_or_alloc_open_stateowner\n                        // find oo1, without NFS4_OO_CONFIRMED\n                         release_openowner\n                          unhash_openowner_locked\n                          list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n                          // cannot find this oo\n                          // from client, LEAK!!!\n                         alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n  init_open_stateid\n  // associate oo1\n  // with stateid1, stateid1 LEAK!!!\n  nfs4_get_vfs_file\n  // alloc nfsd_file1 and nfsd_file_mark1\n  // all LEAK!!!\n\n                         nfsd4_process_open2\n                         ...\n\n                                    write_threads\n                                     ...\n                                     nfsd_destroy_serv\n                                      nfsd_shutdown_net\n                                       nfs4_state_shutdown_net\n                                        nfs4_state_destroy_net\n                                         destroy_client\n                                          __destroy_client\n                                          // won\u0026apos;t find oo1!!!\n                                     nfsd_shutdown_generic\n                                      nfsd_file_cache_shutdown\n                                       kmem_cache_destroy\n                                       for nfsd_file_slab\n                                       and nfsd_file_mark_slab\n                                       // bark since nfsd_file1\n                                       // and nfsd_file_mark1\n                                       // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: imx6: Fix suspend/resume support on i.MX6QDL\n\nThe suspend/resume functionality is currently broken on the i.MX6QDL\nplatform, as documented in the NXP errata (ERR005723):\n\n  https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf\n\nThis patch addresses the issue by sharing most of the suspend/resume\nsequences used by other i.MX devices, while avoiding modifications to\ncritical registers that disrupt the PCIe functionality. It targets the\nsame problem as the following downstream commit:\n\n  https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995\n\nUnlike the downstream commit, this patch also resets the connected PCIe\ndevice if possible. Without this reset, certain drivers, such as ath10k\nor iwlwifi, will crash on resume. The device reset is also done by the\ndriver on other i.MX platforms, making this patch consistent with\nexisting practices.\n\nUpon resuming, the kernel will hang and display an error. Here\u0026apos;s an\nexample of the error encountered with the ath10k driver:\n\n  ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible\n  Unhandled fault: imprecise external abort (0x1406) at 0x0106f944\n\nWithout this patch, suspend/resume will fail on i.MX6QDL devices if a\nPCIe device is connected.\n\n[kwilczynski: commit log, added tag for stable releases](CVE-2024-57809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL\n\nCurrently tagged_addr_ctrl_set() doesn\u0026apos;t initialize the temporary \u0026apos;ctrl\u0026apos;\nvariable, and a SETREGSET call with a length of zero will leave this\nuninitialized. Consequently tagged_addr_ctrl_set() will consume an\narbitrary value, potentially leaking up to 64 bits of memory from the\nkernel stack. The read is limited to a specific slot on the stack, and\nthe issue does not provide a write mechanism.\n\nAs set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and\nrejects other values, a partial SETREGSET attempt will randomly succeed\nor fail depending on the value of the uninitialized value, and the\nexposure is significantly limited.\n\nFix this by initializing the temporary value before copying the regset\nfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,\nNT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing\nvalue of the tagged address ctrl will be retained.\n\nThe NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the\nuser_aarch64_view used by a native AArch64 task to manipulate another\nnative AArch64 task. As get_tagged_addr_ctrl() only returns an error\nvalue when called for a compat task, tagged_addr_ctrl_get() and\ntagged_addr_ctrl_set() should never observe an error value from\nget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that\nsuch an error would be unexpected, and error handlnig is not missing in\neither case.(CVE-2024-57874)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota.  Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed.  Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ti-ads8688: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: vcnl4035: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to userspace from a\ntriggered buffer, but it does not set an initial value for the single\ndata element, which is an u16 aligned to 8 bytes. That leaves at least\n4 bytes uninitialized even after writing an integer value with\nregmap_read().\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntopology: Keep the cpumask unchanged when printing cpumap\n\nDuring fuzz testing, the following warning was discovered:\n\n different return values (15 and 11) from vsnprintf(\u0026quot;%*pbl\n \u0026quot;, ...)\n\n test:keyward is WARNING in kvasprintf\n WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130\n Call Trace:\n  kvasprintf+0x121/0x130\n  kasprintf+0xa6/0xe0\n  bitmap_print_to_buf+0x89/0x100\n  core_siblings_list_read+0x7e/0xb0\n  kernfs_file_read_iter+0x15b/0x270\n  new_sync_read+0x153/0x260\n  vfs_read+0x215/0x290\n  ksys_read+0xb9/0x160\n  do_syscall_64+0x56/0x100\n  entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe call trace shows that kvasprintf() reported this warning during the\nprinting of core_siblings_list. kvasprintf() has several steps:\n\n (1) First, calculate the length of the resulting formatted string.\n\n (2) Allocate a buffer based on the returned length.\n\n (3) Then, perform the actual string formatting.\n\n (4) Check whether the lengths of the formatted strings returned in\n     steps (1) and (2) are consistent.\n\nIf the core_cpumask is modified between steps (1) and (3), the lengths\nobtained in these two steps may not match. Indeed our test includes cpu\nhotplugging, which should modify core_cpumask while printing.\n\nTo fix this issue, cache the cpumask into a temporary variable before\ncalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged\nduring the printing process.(CVE-2024-57917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add check for granularity in dml ceil/floor helpers\n\n[Why]\nWrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()\nshould check for granularity is non zero to avoid assert and\ndivide-by-zero error in dcn_bw_ functions.\n\n[How]\nAdd check for granularity 0.\n\n(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)(CVE-2024-57922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Set private-\u0026gt;all_drm_private[i]-\u0026gt;drm to NULL if mtk_drm_bind returns err\n\nThe pointer need to be set to NULL, otherwise KASAN complains about\nuse-after-free. Because in mtk_drm_bind, all private\u0026apos;s drm are set\nas follows.\n\nprivate-\u0026gt;all_drm_private[i]-\u0026gt;drm = drm;\n\nAnd drm will be released by drm_dev_put in case mtk_drm_kms_init returns\nfailure. However, the shutdown path still accesses the previous allocated\nmemory in drm_atomic_helper_shutdown.\n\n[   84.874820] watchdog: watchdog0: watchdog did not stop!\n[   86.512054] ==================================================================\n[   86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378\n[   86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1\n[   86.515213]\n[   86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55\n[   86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022\n[   86.517960] Call trace:\n[   86.518333]  show_stack+0x20/0x38 (C)\n[   86.518891]  dump_stack_lvl+0x90/0xd0\n[   86.519443]  print_report+0xf8/0x5b0\n[   86.519985]  kasan_report+0xb4/0x100\n[   86.520526]  __asan_report_load8_noabort+0x20/0x30\n[   86.521240]  drm_atomic_helper_shutdown+0x33c/0x378\n[   86.521966]  mtk_drm_shutdown+0x54/0x80\n[   86.522546]  platform_shutdown+0x64/0x90\n[   86.523137]  device_shutdown+0x260/0x5b8\n[   86.523728]  kernel_restart+0x78/0xf0\n[   86.524282]  __do_sys_reboot+0x258/0x2f0\n[   86.524871]  __arm64_sys_reboot+0x90/0xd8\n[   86.525473]  invoke_syscall+0x74/0x268\n[   86.526041]  el0_svc_common.constprop.0+0xb0/0x240\n[   86.526751]  do_el0_svc+0x4c/0x70\n[   86.527251]  el0_svc+0x4c/0xc0\n[   86.527719]  el0t_64_sync_handler+0x144/0x168\n[   86.528367]  el0t_64_sync+0x198/0x1a0\n[   86.528920]\n[   86.529157] The buggy address belongs to the physical page:\n[   86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc\n[   86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)\n[   86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000\n[   86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000\n[   86.534511] page dumped because: kasan: bad access detected\n[   86.535323]\n[   86.535559] Memory state around the buggy address:\n[   86.536265]  ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.537314]  ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.538363] \u0026gt;ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.544733]                                                           ^\n[   86.551057]  ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.557510]  ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.563928] ==================================================================\n[   86.571093] Disabling lock debugging due to kernel taint\n[   86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b\n[   86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]\n...(CVE-2024-57926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure shadow stack is active before \u0026quot;getting\u0026quot; registers\n\nThe x86 shadow stack support has its own set of registers. Those registers\nare XSAVE-managed, but they are \u0026quot;supervisor state components\u0026quot; which means\nthat userspace can not touch them with XSAVE/XRSTOR.  It also means that\nthey are not accessible from the existing ptrace ABI for XSAVE state.\nThus, there is a new ptrace get/set interface for it.\n\nThe regset code that ptrace uses provides an -\u0026gt;active() handler in\naddition to the get/set ones. For shadow stack this -\u0026gt;active() handler\nverifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the\nthread struct. The -\u0026gt;active() handler is checked from some call sites of\nthe regset get/set handlers, but not the ptrace ones. This was not\nunderstood when shadow stack support was put in place.\n\nAs a result, both the set/get handlers can be called with\nXFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to\nreturn NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an\nssp_active() check to avoid surprising the kernel with shadow stack\nbehavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That\ncheck just happened to avoid the warning.\n\nBut the -\u0026gt;get() side wasn\u0026apos;t so lucky. It can be called with shadow stacks\ndisabled, triggering the warning in practice, as reported by Christina\nSchimpe:\n\nWARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6e/0x80\n? ssp_get+0x89/0xa0\n? __warn+0x91/0x150\n? ssp_get+0x89/0xa0\n? report_bug+0x19d/0x1b0\n? handle_bug+0x46/0x80\n? exc_invalid_op+0x1d/0x80\n? asm_exc_invalid_op+0x1f/0x30\n? __pfx_ssp_get+0x10/0x10\n? ssp_get+0x89/0xa0\n? ssp_get+0x52/0xa0\n__regset_get+0xad/0xf0\ncopy_regset_to_user+0x52/0xc0\nptrace_regset+0x119/0x140\nptrace_request+0x13c/0x850\n? wait_task_inactive+0x142/0x1d0\n? do_syscall_64+0x6d/0x90\narch_ptrace+0x102/0x300\n[...]\n\nEnsure that shadow stacks are active in a thread before looking them up\nin the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are\nset at the same time, the active check ensures that there will be\nsomething to find in the XSAVE buffer.\n\n[ dhansen: changelog/subject tweaks ](CVE-2025-21632)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid extent tree\n\n[BUG]\nSyzbot reported a crash with the following call trace:\n\n  BTRFS info (device loop0): scrub: started on devid 1\n  BUG: kernel NULL pointer dereference, address: 0000000000000208\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0\n  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G           O       6.13.0-rc4-custom+ #206\n  Tainted: [O]=OOT_MODULE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n  RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]\n   scrub_simple_mirror+0x175/0x260 [btrfs]\n   scrub_stripe+0x5d4/0x6c0 [btrfs]\n   scrub_chunk+0xbb/0x170 [btrfs]\n   scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]\n   btrfs_scrub_dev+0x240/0x600 [btrfs]\n   btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]\n   ? do_sys_openat2+0xa5/0xf0\n   __x64_sys_ioctl+0x97/0xc0\n   do_syscall_64+0x4f/0x120\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u0026lt;/TASK\u0026gt;\n\n[CAUSE]\nThe reproducer is using a corrupted image where extent tree root is\ncorrupted, thus forcing to use \u0026quot;rescue=all,ro\u0026quot; mount option to mount the\nimage.\n\nThen it triggered a scrub, but since scrub relies on extent tree to find\nwhere the data/metadata extents are, scrub_find_fill_first_stripe()\nrelies on an non-empty extent root.\n\nBut unfortunately scrub_find_fill_first_stripe() doesn\u0026apos;t really expect\nan NULL pointer for extent root, it use extent_root to grab fs_info and\ntriggered a NULL pointer dereference.\n\n[FIX]\nAdd an extra check for a valid extent root at the beginning of\nscrub_find_fill_first_stripe().\n\nThe new error path is introduced by 42437a6386ff (\u0026quot;btrfs: introduce\nmount option rescue=ignorebadroots\u0026quot;), but that\u0026apos;s pretty old, and later\ncommit b979547513ff (\u0026quot;btrfs: scrub: introduce helper to find and fill\nsector info for a scrub_stripe\u0026quot;) changed how we do scrub.\n\nSo for kernels older than 6.6, the fix will need manual backport.(CVE-2025-21658)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/bpf: return early if transport is not assigned\n\nSome of the core functions can only be called if the transport\nhas been assigned.\n\nAs Michal reported, a socket might have the transport at NULL,\nfor example after a failed connect(), causing the following trace:\n\n    BUG: kernel NULL pointer dereference, address: 00000000000000a0\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0\n    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+\n    RIP: 0010:vsock_connectible_has_data+0x1f/0x40\n    Call Trace:\n     vsock_bpf_recvmsg+0xca/0x5e0\n     sock_recvmsg+0xb9/0xc0\n     __sys_recvfrom+0xb3/0x130\n     __x64_sys_recvfrom+0x20/0x30\n     do_syscall_64+0x93/0x180\n     entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSo we need to check the `vsk-\u0026gt;transport` in vsock_bpf_recvmsg(),\nespecially for connected sockets (stream/seqpacket) as we already\ndo in __vsock_connectible_recvmsg().(CVE-2025-21670)",
  "id": "OESA-2025-1097",
  "modified": "2026-08-06T11:08:11Z",
  "published": "2025-02-08T11:08:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38571"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38575"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38585"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39474"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39495"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40937"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40989"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42251"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43870"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43875"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43876"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43880"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44957"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46672"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46680"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46694"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46711"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46741"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46847"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46864"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46865"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47730"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49864"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49888"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49926"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49953"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49987"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50077"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50111"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50136"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50147"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50175"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50176"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50181"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50231"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50232"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50240"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50256"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50304"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53051"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53094"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53100"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53106"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53109"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53113"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53120"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53121"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53122"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53123"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53124"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53135"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53139"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53140"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53144"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53145"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53166"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53206"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53207"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53209"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53223"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54193"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56589"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56640"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56641"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56653"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56687"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56718"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56729"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56769"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57874"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57926"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21632"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21658"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21670"
    }
  ],
  "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-2024-26952",
    "CVE-2024-26954",
    "CVE-2024-36479",
    "CVE-2024-36916",
    "CVE-2024-37021",
    "CVE-2024-38571",
    "CVE-2024-38575",
    "CVE-2024-38585",
    "CVE-2024-38621",
    "CVE-2024-39474",
    "CVE-2024-39482",
    "CVE-2024-39495",
    "CVE-2024-40924",
    "CVE-2024-40937",
    "CVE-2024-40949",
    "CVE-2024-40961",
    "CVE-2024-40965",
    "CVE-2024-40989",
    "CVE-2024-41001",
    "CVE-2024-41032",
    "CVE-2024-42110",
    "CVE-2024-42251",
    "CVE-2024-43857",
    "CVE-2024-43870",
    "CVE-2024-43875",
    "CVE-2024-43876",
    "CVE-2024-43877",
    "CVE-2024-43880",
    "CVE-2024-43881",
    "CVE-2024-44957",
    "CVE-2024-44968",
    "CVE-2024-44972",
    "CVE-2024-44975",
    "CVE-2024-45001",
    "CVE-2024-45005",
    "CVE-2024-45007",
    "CVE-2024-45012",
    "CVE-2024-45022",
    "CVE-2024-46672",
    "CVE-2024-46680",
    "CVE-2024-46693",
    "CVE-2024-46694",
    "CVE-2024-46711",
    "CVE-2024-46741",
    "CVE-2024-46833",
    "CVE-2024-46847",
    "CVE-2024-46864",
    "CVE-2024-46865",
    "CVE-2024-47730",
    "CVE-2024-47735",
    "CVE-2024-49864",
    "CVE-2024-49888",
    "CVE-2024-49926",
    "CVE-2024-49939",
    "CVE-2024-49946",
    "CVE-2024-49951",
    "CVE-2024-49953",
    "CVE-2024-49987",
    "CVE-2024-49988",
    "CVE-2024-49998",
    "CVE-2024-50035",
    "CVE-2024-50077",
    "CVE-2024-50096",
    "CVE-2024-50110",
    "CVE-2024-50111",
    "CVE-2024-50136",
    "CVE-2024-50147",
    "CVE-2024-50160",
    "CVE-2024-50175",
    "CVE-2024-50176",
    "CVE-2024-50181",
    "CVE-2024-50183",
    "CVE-2024-50189",
    "CVE-2024-50220",
    "CVE-2024-50221",
    "CVE-2024-50231",
    "CVE-2024-50232",
    "CVE-2024-50240",
    "CVE-2024-50252",
    "CVE-2024-50256",
    "CVE-2024-50295",
    "CVE-2024-50296",
    "CVE-2024-50304",
    "CVE-2024-53051",
    "CVE-2024-53058",
    "CVE-2024-53091",
    "CVE-2024-53093",
    "CVE-2024-53094",
    "CVE-2024-53097",
    "CVE-2024-53100",
    "CVE-2024-53106",
    "CVE-2024-53109",
    "CVE-2024-53113",
    "CVE-2024-53119",
    "CVE-2024-53120",
    "CVE-2024-53121",
    "CVE-2024-53122",
    "CVE-2024-53123",
    "CVE-2024-53124",
    "CVE-2024-53135",
    "CVE-2024-53138",
    "CVE-2024-53139",
    "CVE-2024-53140",
    "CVE-2024-53144",
    "CVE-2024-53145",
    "CVE-2024-53166",
    "CVE-2024-53201",
    "CVE-2024-53206",
    "CVE-2024-53207",
    "CVE-2024-53209",
    "CVE-2024-53223",
    "CVE-2024-53237",
    "CVE-2024-54193",
    "CVE-2024-56557",
    "CVE-2024-56567",
    "CVE-2024-56588",
    "CVE-2024-56589",
    "CVE-2024-56590",
    "CVE-2024-56614",
    "CVE-2024-56623",
    "CVE-2024-56640",
    "CVE-2024-56641",
    "CVE-2024-56653",
    "CVE-2024-56677",
    "CVE-2024-56687",
    "CVE-2024-56688",
    "CVE-2024-56701",
    "CVE-2024-56718",
    "CVE-2024-56729",
    "CVE-2024-56758",
    "CVE-2024-56769",
    "CVE-2024-56779",
    "CVE-2024-57809",
    "CVE-2024-57874",
    "CVE-2024-57892",
    "CVE-2024-57906",
    "CVE-2024-57910",
    "CVE-2024-57917",
    "CVE-2024-57922",
    "CVE-2024-57926",
    "CVE-2025-21632",
    "CVE-2025-21658",
    "CVE-2025-21670"
  ]
}