{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.121.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-218.0.0.121.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\nASoC: SOF: Fix DSP oops stack dump output contents\r\n\r\nFix @buf arg given to hex_dump_to_buffer() and stack address used\nin dump error output.(CVE-2021-47381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9170/1: fix panic when kasan and kprobe are enabled\r\n\r\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\r\n\r\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\r\n\r\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n\u0026lt;cap_capable\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108    ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144]  ;\nebfc7bf8\tbl\tc03aa4b4 \u0026lt;__asan_load4\u0026gt;\ne595706c\tldr\tr7, [r5, #108]  ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 \u0026lt;emulate_ldr\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60     ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc \u0026lt;emulate_ldr+0x38\u0026gt;\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 \u0026lt;emulate_ldr+0xac\u0026gt;\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64     ; 0x40\n......\r\n\r\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c\nr10: 00000000  r9 : c30897f4  r8 : ecd63cd4\nr7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98\nr3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008\nFlags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 32c5387d  Table: 2d546400  DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix use-after-free after failure to create a snapshot\r\n\r\nAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure and\nthen attach it to the transaction\u0026apos;s list of pending snapshots. After that\nwe call btrfs_commit_transaction(), and if that returns an error we jump\nto \u0026apos;fail\u0026apos; label, where we kfree() the pending snapshot structure. This can\nresult in a later use-after-free of the pending snapshot:\r\n\r\n1) We allocated the pending snapshot and added it to the transaction\u0026apos;s\n   list of pending snapshots;\r\n\r\n2) We call btrfs_commit_transaction(), and it fails either at the first\n   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().\n   In both cases, we don\u0026apos;t abort the transaction and we release our\n   transaction handle. We jump to the \u0026apos;fail\u0026apos; label and free the pending\n   snapshot structure. We return with the pending snapshot still in the\n   transaction\u0026apos;s list;\r\n\r\n3) Another task commits the transaction. This time there\u0026apos;s no error at\n   all, and then during the transaction commit it accesses a pointer\n   to the pending snapshot structure that the snapshot creation task\n   has already freed, resulting in a user-after-free.\r\n\r\nThis issue could actually be detected by smatch, which produced the\nfollowing warning:\r\n\r\n  fs/btrfs/ioctl.c:843 create_snapshot() warn: \u0026apos;\u0026amp;pending_snapshot-\u0026gt;list\u0026apos; not removed from list\r\n\r\nSo fix this by not having the snapshot creation ioctl directly add the\npending snapshot to the transaction\u0026apos;s list. Instead add the pending\nsnapshot to the transaction handle, and then at btrfs_commit_transaction()\nwe add the snapshot to the list only when we can guarantee that any error\nreturned after that point will result in a transaction abort, in which\ncase the ioctl code can safely free the pending snapshot and no one can\naccess it anymore.(CVE-2022-48733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Avoid field-overflowing memcpy()\r\n\r\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\r\n\r\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\r\n\r\nWe were doing:\r\n\r\n\t#define ETH_HLEN  14\n\t#define VLAN_HLEN  4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n        struct mlx5_wqe_eth_seg  *eseg = \u0026amp;wqe-\u0026gt;eth;\n        struct mlx5_wqe_data_seg *dseg = wqe-\u0026gt;data;\n\t...\n\tmemcpy(eseg-\u0026gt;inline_hdr.start, xdptxd-\u0026gt;data, MLX5E_XDP_MIN_INLINE);\r\n\r\ntarget is wqe-\u0026gt;eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe-\u0026gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\r\n\r\nstruct mlx5e_tx_wqe {\n        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */\n        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */\n        struct mlx5_wqe_data_seg   data[];               /*    32     0 */\r\n\r\n        /* size: 32, cachelines: 1, members: 3 */\n        /* last cacheline: 32 bytes */\n};\r\n\r\nstruct mlx5_wqe_eth_seg {\n        u8                         swp_outer_l4_offset;  /*     0     1 */\n        u8                         swp_outer_l3_offset;  /*     1     1 */\n        u8                         swp_inner_l4_offset;  /*     2     1 */\n        u8                         swp_inner_l3_offset;  /*     3     1 */\n        u8                         cs_flags;             /*     4     1 */\n        u8                         swp_flags;            /*     5     1 */\n        __be16                     mss;                  /*     6     2 */\n        __be32                     flow_table_metadata;  /*     8     4 */\n        union {\n                struct {\n                        __be16     sz;                   /*    12     2 */\n                        u8         start[2];             /*    14     2 */\n                } inline_hdr;                            /*    12     4 */\n                struct {\n                        __be16     type;                 /*    12     2 */\n                        __be16     vlan_tci;             /*    14     2 */\n                } insert;                                /*    12     4 */\n                __be32             trailer;              /*    12     4 */\n        };                                               /*    12     4 */\r\n\r\n        /* size: 16, cachelines: 1, members: 9 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nstruct mlx5_wqe_data_seg {\n        __be32                     byte_count;           /*     0     4 */\n        __be32                     lkey;                 /*     4     4 */\n        __be64                     addr;                 /*     8     8 */\r\n\r\n        /* size: 16, cachelines: 1, members: 3 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\r\n\r\n\u0026quot;pahole\u0026quot; shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \u0026quot;objdump -d\u0026quot; shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).(CVE-2022-48744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: LAPIC: Also cancel preemption timer during SET_LAPIC\r\n\r\nThe below warning is splatting during guest reboot.\r\n\r\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5\n  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   kvm_vcpu_ioctl+0x279/0x710 [kvm]\n   __x64_sys_ioctl+0x83/0xb0\n   do_syscall_64+0x3b/0xc0\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n  RIP: 0033:0x7fd39797350b\r\n\r\nThis can be triggered by not exposing tsc-deadline mode and doing a reboot in\nthe guest. The lapic_shutdown() function which is called in sys_reboot path\nwill not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears\nAPIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode\nswitch between tsc-deadline and oneshot/periodic, which can result in preemption\ntimer be cancelled in apic_update_lvtt(). However, We can\u0026apos;t depend on this when\nnot exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption\ntimer. Qemu will synchronise states around reset, let\u0026apos;s cancel preemption timer\nunder KVM_SET_LAPIC.(CVE-2022-48765)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: lgdt3306a: Add a check against null-pointer-def\r\n\r\nThe driver should check whether the client provides the platform_data.\r\n\r\nThe following log reveals it:\r\n\r\n[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40\n[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414\n[   29.612820] Call Trace:\n[   29.613030]  \u0026lt;TASK\u0026gt;\n[   29.613201]  dump_stack_lvl+0x56/0x6f\n[   29.613496]  ? kmemdup+0x30/0x40\n[   29.613754]  print_report.cold+0x494/0x6b7\n[   29.614082]  ? kmemdup+0x30/0x40\n[   29.614340]  kasan_report+0x8a/0x190\n[   29.614628]  ? kmemdup+0x30/0x40\n[   29.614888]  kasan_check_range+0x14d/0x1d0\n[   29.615213]  memcpy+0x20/0x60\n[   29.615454]  kmemdup+0x30/0x40\n[   29.615700]  lgdt3306a_probe+0x52/0x310\n[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btusb: Add date-\u0026gt;evt_skb is NULL check\r\n\r\nfix crash because of null pointers\r\n\r\n[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8\n[ 6104.969667] #PF: supervisor read access in kernel mode\n[ 6104.969668] #PF: error_code(0x0000) - not-present page\n[ 6104.969670] PGD 0 P4D 0\n[ 6104.969673] Oops: 0000 [#1] SMP NOPTI\n[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]\n[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246\n[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006\n[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000\n[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001\n[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0\n[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90\n[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000\n[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0\n[ 6104.969701] PKRU: 55555554\n[ 6104.969702] Call Trace:\n[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]\n[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]\n[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]\n[ 6104.969753]  rfkill_set_block+0x92/0x160\n[ 6104.969755]  rfkill_fop_write+0x136/0x1e0\n[ 6104.969759]  __vfs_write+0x18/0x40\n[ 6104.969761]  vfs_write+0xdf/0x1c0\n[ 6104.969763]  ksys_write+0xb1/0xe0\n[ 6104.969765]  __x64_sys_write+0x1a/0x20\n[ 6104.969769]  do_syscall_64+0x51/0x180\n[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[ 6104.969773] RIP: 0033:0x7f5a21f18fef\n[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\n[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef\n[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012\n[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017\n[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002\n[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: dynamic: Synchronize of_changeset_destroy() with the devlink removals\r\n\r\nIn the following sequence:\n  1) of_platform_depopulate()\n  2) of_overlay_remove()\r\n\r\nDuring the step 1, devices are destroyed and devlinks are removed.\nDuring the step 2, OF nodes are destroyed but\n__of_changeset_entry_destroy() can raise warnings related to missing\nof_node_put():\n  ERROR: memory leak, expected refcount 1 instead of 2 ...\r\n\r\nIndeed, during the devlink removals performed at step 1, the removal\nitself releasing the device (and the attached of_node) is done by a job\nqueued in a workqueue and so, it is done asynchronously with respect to\nfunction calls.\nWhen the warning is present, of_node_put() will be called but wrongly\ntoo late from the workqueue job.\r\n\r\nIn order to be sure that any ongoing devlink removals are done before\nthe of_node destruction, synchronize the of_changeset_destroy() with the\ndevlink removals.(CVE-2024-35879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_skbmod: prevent kernel-infoleak\r\n\r\nsyzbot found that tcf_skbmod_dump() was copying four bytes\nfrom kernel stack to user space [1].\r\n\r\nThe issue here is that \u0026apos;struct tc_skbmod\u0026apos; has a four bytes hole.\r\n\r\nWe need to clear the structure before filling fields.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n  copy_to_user_iter lib/iov_iter.c:24 [inline]\n  iterate_ubuf include/linux/iov_iter.h:29 [inline]\n  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n  iterate_and_advance include/linux/iov_iter.h:271 [inline]\n  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  copy_to_iter include/linux/uio.h:196 [inline]\n  simple_copy_to_iter net/core/datagram.c:532 [inline]\n  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420\n  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]\n  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242\n  __do_sys_recvfrom net/socket.c:2260 [inline]\n  __se_sys_recvfrom net/socket.c:2256 [inline]\n  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253\n  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317\n  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351\n  nlmsg_unicast include/net/netlink.h:1144 [inline]\n  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610\n  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741\n  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]\n  tcf_add_notify net/sched/act_api.c:2048 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559\n  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613\n  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361\n  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n  __sys_sendmsg net/socket.c:2667 [inline]\n  __do_sys_sendmsg net/socket.c:2676 [inline]\n  __se_sys_sendmsg net/socket.c:2674 [inline]\n  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  __nla_put lib/nlattr.c:1041 [inline]\n  nla_put+0x1c6/0x230 lib/nlattr.c:1099\n  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256\n  tcf_action_dump_old net/sched/act_api.c:1191 [inline]\n  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227\n  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251\n  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628\n  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]\n  tcf_add_notify net/sched/act_api.c:2042 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli\n---truncated---(CVE-2024-35893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr\r\n\r\nAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it\nstill means hlist_for_each_entry_rcu can return an item that got removed\nfrom the list. The memory itself of such item is not freed thanks to RCU\nbut nothing guarantees the actual content of the memory is sane.\r\n\r\nIn particular, the reference count can be zero. This can happen if\nipv6_del_addr is called in parallel. ipv6_del_addr removes the entry\nfrom inet6_addr_lst (hlist_del_init_rcu(\u0026amp;ifp-\u0026gt;addr_lst)) and drops all\nreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough\ntiming, this can happen:\r\n\r\n1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.\r\n\r\n2. Then, the whole ipv6_del_addr is executed for the given entry. The\n   reference count drops to zero and kfree_rcu is scheduled.\r\n\r\n3. ipv6_get_ifaddr continues and tries to increments the reference count\n   (in6_ifa_hold).\r\n\r\n4. The rcu is unlocked and the entry is freed.\r\n\r\n5. The freed entry is returned.\r\n\r\nPrevent increasing of the reference count in such case. The name\nin6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.\r\n\r\n[   41.506330] refcount_t: addition on 0; use-after-free.\n[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130\n[   41.507413] Modules linked in: veth bridge stp llc\n[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14\n[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130\n[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 \u0026lt;0f\u0026gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff\n[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282\n[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000\n[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900\n[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff\n[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000\n[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48\n[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000\n[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0\n[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[   41.516799] Call Trace:\n[   41.517037]  \u0026lt;TASK\u0026gt;\n[   41.517249]  ? __warn+0x7b/0x120\n[   41.517535]  ? refcount_warn_saturate+0xa5/0x130\n[   41.517923]  ? report_bug+0x164/0x190\n[   41.518240]  ? handle_bug+0x3d/0x70\n[   41.518541]  ? exc_invalid_op+0x17/0x70\n[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20\n[   41.521325]  ? refcount_warn_saturate+0xa5/0x130\n[   41.521708]  ipv6_get_ifaddr+0xda/0xe0\n[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0\n[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10\n[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0\n[   41.523102]  ? netlink_unicast+0x30f/0x390\n[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[   41.523832]  netlink_rcv_skb+0x53/0x100\n[   41.524157]  netlink_unicast+0x23b/0x390\n[   41.524484]  netlink_sendmsg+0x1f2/0x440\n[   41.524826]  __sys_sendto+0x1d8/0x1f0\n[   41.525145]  __x64_sys_sendto+0x1f/0x30\n[   41.525467]  do_syscall_64+0xa5/0x1b0\n[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a\n[   41.526213] RIP: 0033:0x7fbc4cfcea9a\n[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89\n[   41.527942] RSP: 002b:00007f\n---truncated---(CVE-2024-35969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Fix TASK_SIZE on 64-bit NOMMU\r\n\r\nOn NOMMU, userspace memory can come from anywhere in physical RAM. The\ncurrent definition of TASK_SIZE is wrong if any RAM exists above 4G,\ncausing spurious failures in the userspace access routines.(CVE-2024-35988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/arm/malidp: fix a possible null pointer dereference\r\n\r\nIn malidp_mw_connector_reset, new memory is allocated with kzalloc, but\nno check is performed. In order to prevent null pointer dereferencing,\nensure that mw_state is checked before calling\n__drm_atomic_helper_connector_reset.(CVE-2024-36014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntls: fix missing memory barrier in tls_init\r\n\r\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\r\n\r\nCPU0                               CPU1\n-----                              -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx-\u0026gt;sk_proto = READ_ONCE(sk-\u0026gt;sk_prot) -(1)\r\n\r\n// In update_sk_prot()\nWRITE_ONCE(sk-\u0026gt;sk_prot, tls_prots)     -(2)\r\n\r\n                                   // In sock_common_setsockopt()\n                                   READ_ONCE(sk-\u0026gt;sk_prot)-\u0026gt;setsockopt()\r\n\r\n                                   // In tls_{setsockopt,getsockopt}()\n                                   ctx-\u0026gt;sk_proto-\u0026gt;setsockopt()    -(3)\r\n\r\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx-\u0026gt;sk_proto, causing NULL dereference.\r\n\r\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx-\u0026gt;sk_proto is\ninitialized, we can ensure that ctx-\u0026gt;sk_proto are visible when\nchanging sk-\u0026gt;sk_prot.(CVE-2024-36489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\r\n\r\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\r\n\r\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u0026lt;TASK\u0026gt;\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\r\n\r\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\r\n\r\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\r\n\r\nWith the following stack trace:\r\n\r\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\r\n\r\nSo we\u0026apos;re logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\r\n\r\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\r\n\r\n  \u0026gt;\u0026gt;\u0026gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][\u0026quot;eb\u0026quot;])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\r\n\r\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\r\n\r\nHere is the state of \n---truncated---(CVE-2024-37354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_rx_work\r\n\r\nsyzbot reported the following uninit-value access issue [1]\r\n\r\nnci_rx_work() parses received packet from ndev-\u0026gt;rx_q. It should be\nvalidated header size, payload size and total packet size before\nprocessing the packet. If an invalid packet is detected, it should be\nsilently discarded.(CVE-2024-38381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\r\n\r\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\r\n\r\nsh_css_pipe_load_binaries()\n  |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n  |\n  |-\u0026gt; sh_css_pipe_unload_binaries()\n        |-\u0026gt; unload_video_binaries()\r\n\r\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow\r\n\r\nThere is a possibility of buffer overflow in\nshow_rcu_tasks_trace_gp_kthread() if counters, passed\nto sprintf() are huge. Counter numbers, needed for this\nare unrealistically high, but buffer overflow is still\npossible.\r\n\r\nUse snprintf() with buffer size instead of sprintf().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: bcm - Fix pointer arithmetic\r\n\r\nIn spu2_dump_omd() value of ptr is increased by ciph_key_len\ninstead of hash_iv_len which could lead to going beyond the\nbuffer boundaries.\nFix this bug by changing ciph_key_len to hash_iv_len.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n  nilfs_segctor_destroy\n    nilfs_segctor_kill_thread  --\u0026gt; Shut down log writer thread\n    flush_work\n      nilfs_iput_work_func\n        nilfs_dispose_list\n          iput\n            nilfs_evict_inode\n              nilfs_transaction_commit\n                nilfs_construct_segment (if inode needs sync)\n                  nilfs_segctor_sync  --\u0026gt; Attempt to synchronize with\n                                          log writer thread\n                           *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis.  Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Modify the print level of CQE error\r\n\r\nToo much print may lead to a panic in kernel. Change ibdev_err() to\nibdev_err_ratelimited(), and change the printing level of cqe dump\nto debug level.(CVE-2024-38590)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix resync softlockup when bitmap size is less than array size\r\n\r\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\r\n\r\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\r\n\r\nAnd the detailed process is as follows:\r\n\r\nmd_do_sync\n j = mddev-\u0026gt;resync_min\n while (j \u0026lt; max_sectors)\n  sectors = raid10_sync_request(mddev, j, \u0026amp;skipped)\n   if (!md_bitmap_start_sync(..., \u0026amp;sync_blocks))\n    // md_bitmap_start_sync set sync_blocks to 0\n    return sync_blocks + sectors_skippe;\n  // sectors = 0;\n  j += sectors;\n  // j never change\r\n\r\nRoot cause is that commit 301867b1c168 (\u0026quot;md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\u0026quot;) return early from\nmd_bitmap_get_counter(), without setting returned blocks.\r\n\r\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\u0026quot;(), as it used to be.\r\n\r\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0026apos;t match array size still need to be fixed.(CVE-2024-38598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issues of ax25_dev\r\n\r\nThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference\ncount leak issue of the object \u0026quot;ax25_dev\u0026quot;.\r\n\r\nMemory leak issue in ax25_addr_ax25dev():\r\n\r\nThe reference count of the object \u0026quot;ax25_dev\u0026quot; can be increased multiple\ntimes in ax25_addr_ax25dev(). This will cause a memory leak.\r\n\r\nMemory leak issues in ax25_dev_device_down():\r\n\r\nThe reference count of ax25_dev is set to 1 in ax25_dev_device_up() and\nthen increase the reference count when ax25_dev is added to ax25_dev_list.\nAs a result, the reference count of ax25_dev is 2. But when the device is\nshutting down. The ax25_dev_device_down() drops the reference count once\nor twice depending on if we goto unlock_put or not, which will cause\nmemory leak.\r\n\r\nAs for the issue of ax25_addr_ax25dev(), it is impossible for one pointer\nto be on a list twice. So add a break in ax25_addr_ax25dev(). As for the\nissue of ax25_dev_device_down(), increase the reference count of ax25_dev\nonce in ax25_dev_device_up() and decrease the reference count of ax25_dev\nafter it is removed from the ax25_dev_list.(CVE-2024-38602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()\r\n\r\npci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()\nfails, the irq vector is not freed, which leads to a memory leak.\r\n\r\nReplace the devm_add_action with devm_add_action_or_reset to ensure\nthe irq vector can be destroyed when it fails.(CVE-2024-38603)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: exit() callback is optional\r\n\r\nThe exit() callback is optional and shouldn\u0026apos;t be called without checking\na valid pointer first.\r\n\r\nAlso, we must clear freq_table pointer even if the exit() callback isn\u0026apos;t\npresent.(CVE-2024-38615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\r\n\r\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\r\n\r\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\r\n\r\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use variable length array instead of fixed size\r\n\r\nShould fix smatch warning:\n\tntfs_set_label() error: __builtin_memcpy() \u0026apos;uni-\u0026gt;name\u0026apos; too small (20 vs 256)(CVE-2024-38623)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Check \u0026apos;folio\u0026apos; pointer for NULL\r\n\r\nIt can be NULL if bmap is called.(CVE-2024-38625)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Update uart_driver_registered on driver removal\r\n\r\nThe removal of the last MAX3100 device triggers the removal of\nthe driver. However, code doesn\u0026apos;t update the respective global\nvariable and after insmod \u2014 rmmod \u2014 insmod cycle the kernel\noopses:\r\n\r\n  max3100 spi-PRP0001:01: max3100_probe: adding port 0\n  BUG: kernel NULL pointer dereference, address: 0000000000000408\n  ...\n  RIP: 0010:serial_core_register_port+0xa0/0x840\n  ...\n   max3100_probe+0x1b6/0x280 [max3100]\n   spi_probe+0x8d/0xb0\r\n\r\nUpdate the actual state so next time UART driver will be registered\nagain.\r\n\r\nHugo also noticed, that the error path in the probe also affected\nby having the variable set, and not cleared. Instead of clearing it\nmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n  ...\n  Workqueue: max3100-0 max3100_work [max3100]\n  RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n  ...\n   max3100_handlerx+0xc5/0x110 [max3100]\n   max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngreybus: lights: check return of get_channel_from_mode\r\n\r\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\r\n\r\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf/sw-sync: don\u0026apos;t enable IRQ from sync_print_obj()\r\n\r\nSince commit a6aa8fca4d79 (\u0026quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\u0026quot;) by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\r\n\r\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/9p: fix uninit-value in p9_client_rpc()\r\n\r\nSyzbot with the help of KMSAN reported the following error:\r\n\r\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nIf p9_check_errors() fails early in p9_client_rpc(), req-\u0026gt;rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\r\n\r\nFix this issue by assigning default values to p9_fcall fields\nsuch as \u0026apos;tag\u0026apos; and (just in case KMSAN unearths something new) \u0026apos;id\u0026apos;\nduring the tag allocation stage.(CVE-2024-39301)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()\r\n\r\nsyzbot reports a kernel bug as below:\r\n\r\nF2FS-fs (loop0): Mounted with checkpoint version = 48b305e4\n==================================================================\nBUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\nBUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]\nBUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\nRead of size 1 at addr ffff88807a58c76c by task syz-executor280/5076\r\n\r\nCPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\n current_nat_addr fs/f2fs/node.h:213 [inline]\n f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\n f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]\n f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838\n __do_sys_ioctl fs/ioctl.c:902 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nThe root cause is we missed to do sanity check on i_xattr_nid during\nf2fs_iget(), so that in fiemap() path, current_nat_addr() will access\nnat_bitmap w/ offset from invalid i_xattr_nid, result in triggering\nkasan bug report, fix it.(CVE-2024-39467)",
  "id": "OESA-2024-1839",
  "modified": "2026-08-06T11:07:18Z",
  "published": "2024-07-12T11:07:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48765"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38552"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38579"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38603"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38615"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38633"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39467"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47381",
    "CVE-2021-47618",
    "CVE-2022-48733",
    "CVE-2022-48744",
    "CVE-2022-48765",
    "CVE-2022-48772",
    "CVE-2023-52833",
    "CVE-2024-31076",
    "CVE-2024-35879",
    "CVE-2024-35893",
    "CVE-2024-35969",
    "CVE-2024-35988",
    "CVE-2024-36014",
    "CVE-2024-36489",
    "CVE-2024-37353",
    "CVE-2024-37354",
    "CVE-2024-38381",
    "CVE-2024-38547",
    "CVE-2024-38552",
    "CVE-2024-38554",
    "CVE-2024-38577",
    "CVE-2024-38579",
    "CVE-2024-38582",
    "CVE-2024-38583",
    "CVE-2024-38590",
    "CVE-2024-38598",
    "CVE-2024-38602",
    "CVE-2024-38603",
    "CVE-2024-38615",
    "CVE-2024-38621",
    "CVE-2024-38623",
    "CVE-2024-38625",
    "CVE-2024-38633",
    "CVE-2024-38634",
    "CVE-2024-38637",
    "CVE-2024-38780",
    "CVE-2024-39301",
    "CVE-2024-39362",
    "CVE-2024-39467"
  ]
}

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-247.0.0.146.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-247.0.0.146.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.\n\n\n\n\n(CVE-2024-24858)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/membarrier: reduce the ability to hammer on sys_membarrier\n\nOn some systems, sys_membarrier can be very expensive, causing overall\nslowdowns for everything.  So put a lock on the path in order to\nserialize the accesses to prevent the ability for this to be called at\ntoo high of a frequency and saturate the machine.(CVE-2024-26602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed\n\nIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER\nhandler cannot perform VF register successfully as the register call\nis received before netvsc_probe is finished. This is because we\nregister register_netdevice_notifier() very early( even before\nvmbus_driver_register()).\nTo fix this, we try to register each such matching VF( if it is visible\nas a netdevice) at the end of netvsc_probe.(CVE-2024-26820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: make sure to pull inner header in geneve_rx()\n\nsyzbot triggered a bug in geneve_rx() [1]\n\nIssue is similar to the one I fixed in commit 8d975c15c0cd\n(\u0026quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\u0026quot;)\n\nWe have to save skb-\u0026gt;network_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb-\u0026gt;head.\n\n[1]\nBUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]\n BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n  geneve_rx drivers/net/geneve.c:279 [inline]\n  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108\n  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186\n  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346\n  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422\n  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604\n  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n  dst_input include/net/dst.h:461 [inline]\n  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n  process_backlog+0x480/0x8b0 net/core/dev.c:5976\n  __napi_poll+0xe3/0x980 net/core/dev.c:6576\n  napi_poll net/core/dev.c:6645 [inline]\n  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778\n  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553\n  do_softirq+0x9a/0xf0 kernel/softirq.c:454\n  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381\n  local_bh_enable include/linux/bottom_half.h:33 [inline]\n  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]\n  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378\n  dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3081 [inline]\n  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  __sys_sendto+0x735/0xa10 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3819 [inline]\n  slab_alloc_node mm/slub.c:3860 [inline]\n  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n  __alloc_skb+0x352/0x790 net/core/skbuff.c:651\n  alloc_skb include/linux/skbuff.h:1296 [inline]\n  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394\n  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783\n  packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n  packet_snd net/packet/af_packet.c:3024 [inline]\n  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  __sys_sendto+0x735/0xa10 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\n\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\n\nThis resolves a kernel BUG reported by syzbot.  Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\n\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\n\n\nThis patch (of 2):\n\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\n\nThere are two flaws involved in this issue.\n\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block().  This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\n\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state.  This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\n\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above.  Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - resolve race condition during AER recovery\n\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\n\nThis results in a KFENCE bug notice.\n\n  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n  adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  process_one_work+0x173/0x340\n\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix OOB in nilfs_set_de_type\n\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\n\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\n\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\n\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied.  Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix incomplete endpoint checking\n\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\n\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\n\nThis patch has not been tested on real hardware.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\n\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\n\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\n\nsh_css_pipe_load_binaries()\n  |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n  |\n  |-\u0026gt; sh_css_pipe_unload_binaries()\n        |-\u0026gt; unload_video_binaries()\n\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\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\ns390/sclp: Prevent release of buffer in I/O\n\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\n\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n   access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n  (...snip...)\n  The buggy address belongs to the virtual mapping at\n   [ffffc900000f3000, ffffc900000f5000) created by:\n   cache_ctr+0x176a/0x35f0\n\n  (...snip...)\n  Memory state around the buggy address:\n   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n                     ^\n   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in hdcp2_get_capability\n\nAdd encoder check in intel_hdcp2_get_capability to avoid\nnull pointer error.(CVE-2024-53050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()\n\nib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.\nThe driver needs to check whether it is a NULL pointer before\ndereferencing it.(CVE-2024-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix NULL pointer dereference in object-\u0026gt;file\n\nAt present, the object-\u0026gt;file has the NULL pointer dereference problem in\nondemand-mode. The root cause is that the allocated fd and object-\u0026gt;file\nlifetime are inconsistent, and the user-space invocation to anon_fd uses\nobject-\u0026gt;file. Following is the process that triggers the issue:\n\n\t  [write fd]\t\t\t\t[umount]\ncachefiles_ondemand_fd_write_iter\n\t\t\t\t       fscache_cookie_state_machine\n\t\t\t\t\t cachefiles_withdraw_cookie\n  if (!file) return -ENOBUFS\n\t\t\t\t\t   cachefiles_clean_up_object\n\t\t\t\t\t     cachefiles_unmark_inode_in_use\n\t\t\t\t\t     fput(object-\u0026gt;file)\n\t\t\t\t\t     object-\u0026gt;file = NULL\n  // file NULL pointer dereference!\n  __cachefiles_write(..., file, ...)\n\nFix this issue by add an additional reference count to the object-\u0026gt;file\nbefore write/llseek, and decrement after it finished.(CVE-2024-56549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write\n\nAn offset from client could be a negative value, It could allows\nto write data outside the bounds of the allocated buffer.\nNote that this issue is coming when setting\n\u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf..(CVE-2024-56626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n  xmit_one net/core/dev.c:3590 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n  dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3146 [inline]\n  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\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:4091 [inline]\n  slab_alloc_node mm/slub.c:4134 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\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:1323 [inline]\n  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n  packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n  packet_snd net/packet/af_packet.c:3089 [inline]\n  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\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(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)\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)",
  "id": "OESA-2025-1081",
  "modified": "2026-08-06T11:08:10Z",
  "published": "2025-01-24T11:08:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1081"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26820"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53050"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53226"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56549"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56626"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56690"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56758"
    }
  ],
  "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-24858",
    "CVE-2024-26602",
    "CVE-2024-26820",
    "CVE-2024-26857",
    "CVE-2024-26956",
    "CVE-2024-26966",
    "CVE-2024-26969",
    "CVE-2024-26974",
    "CVE-2024-26981",
    "CVE-2024-27001",
    "CVE-2024-38547",
    "CVE-2024-38621",
    "CVE-2024-44969",
    "CVE-2024-50279",
    "CVE-2024-53050",
    "CVE-2024-53226",
    "CVE-2024-56549",
    "CVE-2024-56626",
    "CVE-2024-56648",
    "CVE-2024-56690",
    "CVE-2024-56728",
    "CVE-2024-56758"
  ]
}

{
  "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"
  ]
}