{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2023-52674"
      ],
      "id": "GSD-2023-52674",
      "modified": "2024-03-08T06:01:59.331438Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@mitre.org",
        "ID": "CVE-2023-52674",
        "STATE": "RESERVED"
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
          }
        ]
      }
    }
  }
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-201.0.0.114.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-devel-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-201.0.0.114.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-201.0.0.114.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume\r\n\r\nIn current code, when a PCI error state pci_channel_io_normal is detectd,\nit will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI\ndriver will continue the execution of PCI resume callback report_resume by\npci_walk_bridge, and the callback will go into amdgpu_pci_resume\nfinally, where write lock is releasd unconditionally without acquiring\nsuch lock first. In this case, a deadlock will happen when other threads\nstart to acquire the read lock.\r\n\r\nTo fix this, add a member in amdgpu_device strucutre to cache\npci_channel_state, and only continue the execution in amdgpu_pci_resume\nwhen it\u0026apos;s pci_channel_io_frozen.(CVE-2021-47421)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n  comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n  hex dump (first 8 bytes):\n    70 74 70 30 00 00 00 00                          ptp0....\n  backtrace:\n    [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n    [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n    [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n    [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n    [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n    [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n    [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: enetc: deny offload of tc-based TSN features on VF interfaces\r\n\r\nTSN features on the ENETC (taprio, cbs, gate, police) are configured\nthrough a mix of command BD ring messages and port registers:\nenetc_port_rd(), enetc_port_wr().\r\n\r\nPort registers are a region of the ENETC memory map which are only\naccessible from the PCIe Physical Function. They are not accessible from\nthe Virtual Functions.\r\n\r\nMoreover, attempting to access these registers crashes the kernel:\r\n\r\n$ echo 1 \u0026gt; /sys/bus/pci/devices/0000\\:00\\:00.0/sriov_numvfs\npci 0000:00:01.0: [1957:ef00] type 00 class 0x020001\nfsl_enetc_vf 0000:00:01.0: Adding to iommu group 15\nfsl_enetc_vf 0000:00:01.0: enabling device (0000 -\u0026gt; 0002)\nfsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0\n$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2\nUnable to handle kernel paging request at virtual address ffff800009551a08\nInternal error: Oops: 96000007 [#1] PREEMPT SMP\npc : enetc_setup_tc_taprio+0x170/0x47c\nlr : enetc_setup_tc_taprio+0x16c/0x47c\nCall trace:\n enetc_setup_tc_taprio+0x170/0x47c\n enetc_setup_tc+0x38/0x2dc\n taprio_change+0x43c/0x970\n taprio_init+0x188/0x1e0\n qdisc_create+0x114/0x470\n tc_modify_qdisc+0x1fc/0x6c0\n rtnetlink_rcv_msg+0x12c/0x390\r\n\r\nSplit enetc_setup_tc() into separate functions for the PF and for the\nVF drivers. Also remove enetc_qos.o from being included into\nenetc-vf.ko, since it serves absolutely no purpose there.(CVE-2022-48645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx-\u0026gt;mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: eliminate double free in error handling logic\r\n\r\nDriver has a logic leak in ring data allocation/free,\nwhere aq_ring_free could be called multiple times on same ring,\nif system is under stress and got memory allocation error.\r\n\r\nRing pointer was used as an indicator of failure, but this is\nnot correct since only ring data is allocated/deallocated.\nRing itself is an array member.\r\n\r\nChanging ring allocation functions to return error code directly.\nThis simplifies error handling and eliminates aq_ring_free\non higher layer.(CVE-2023-52664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()\r\n\r\nEnsure the value passed to scarlett2_mixer_ctl_put() is between 0 and\nSCARLETT2_MIXER_MAX_VALUE so we don\u0026apos;t attempt to access outside\nscarlett2_mixer_values[].(CVE-2023-52674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n  comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n  hex dump (first 32 bytes):\n    00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n    [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n    [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n    [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n    [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n    [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n    [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n    [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n    [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n    [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n    [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n    [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n    [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n    [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n    [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n    [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n    [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n    [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add validity check for db_maxag and db_agpref\r\n\r\nBoth db_maxag and db_agpref are used as the index of the\ndb_agfree array, but there is currently no validity check for\ndb_maxag and db_agpref, which can lead to errors.\r\n\r\nThe following is related bug reported by Syzbot:\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20\nindex 7936 is out of range for type \u0026apos;atomic_t[128]\u0026apos;\r\n\r\nAdd checking that the values of db_maxag and db_agpref are valid\nindexes for the db_agfree array.(CVE-2023-52804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diAlloc\r\n\r\nCurrently there is not check against the agno of the iag while\nallocating new inodes to avoid fragmentation problem. Added the check\nwhich is required.(CVE-2023-52805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\r\n\r\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.(CVE-2023-52809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G           OE     5.15.0-43-generic #46-Ubunt       u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS:  00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636]  \u0026lt;TASK\u0026gt;\n[4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002]  full_proxy_read+0x5c/0x80\n[4005007.703011]  vfs_read+0x9f/0x1a0\n[4005007.703019]  ksys_read+0x67/0xe0\n[4005007.703023]  __x64_sys_read+0x19/0x20\n[4005007.703028]  do_syscall_64+0x5c/0xc0\n[4005007.703034]  ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052]  ? irqentry_exit+0x19/0x30\n[4005007.703057]  ? exc_page_fault+0x89/0x160\n[4005007.703062]  ? asm_exc_page_fault+0x8/0x30\n[4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f        1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e       c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105]  \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_       iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t       tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm       i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo       mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v       2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core        drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n    failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n    failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: psi: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\n strlen lib/string.c:418 [inline]\n strstr+0xb8/0x2f0 lib/string.c:756\n tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\n genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\n genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\n netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\n netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\r\n\r\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\r\n\r\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.(CVE-2023-52845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Prevent use after free in prp_create_tagged_frame()\r\n\r\nThe prp_fill_rct() function can fail.  In that situation, it frees the\nskb and returns NULL.  Meanwhile on the success path, it returns the\noriginal skb.  So it\u0026apos;s straight forward to fix bug by using the returned\nvalue.(CVE-2023-52846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0                cpu1\n                  bttv_probe\n                    -\u0026gt;timer_setup\n                      -\u0026gt;bttv_set_dma\n                        -\u0026gt;mod_timer;\nbttv_remove\n  -\u0026gt;kfree(btv);\n                  -\u0026gt;bttv_irq_timeout\n                    -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix refcnt handling in padata_free_shell()\r\n\r\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I\u0026apos;ll describe the problem scenario\nusing a simplified model:\r\n\r\nSuppose there\u0026apos;s a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\r\n\r\n```c\nstruct request {\n    struct padata_priv padata;\n    struct completion *done;\n};\r\n\r\nvoid parallel(struct padata_priv *padata) {\n    do_something();\n}\r\n\r\nvoid serial(struct padata_priv *padata) {\n    struct request *request = container_of(padata,\n    \t\t\t\tstruct request,\n\t\t\t\tpadata);\n    complete(request-\u0026gt;done);\n}\r\n\r\nvoid user_function() {\n    DECLARE_COMPLETION(done)\n    padata-\u0026gt;parallel = parallel;\n    padata-\u0026gt;serial = serial;\n    padata_do_parallel();\n    wait_for_completion(\u0026amp;done);\n    padata_free_shell();\n}\n```\r\n\r\nIn the corresponding padata.c file, there\u0026apos;s the following code:\r\n\r\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n    ...\n    cnt = 0;\r\n\r\n    while (!list_empty(\u0026amp;local_list)) {\n        ...\n        padata-\u0026gt;serial(padata);\n        cnt++;\n    }\r\n\r\n    local_bh_enable();\r\n\r\n    if (refcount_sub_and_test(cnt, \u0026amp;pd-\u0026gt;refcnt))\n        padata_free_pd(pd);\n}\n```\r\n\r\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd-\u0026gt;refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd-\u0026gt;refcnt`.\r\n\r\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`.(CVE-2023-52854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (axi-fan-control) Fix possible NULL pointer dereference\r\n\r\naxi_fan_control_irq_handler(), dependent on the private\naxi_fan_control_data structure, might be called before the hwmon\ndevice is registered. That will cause an \u0026quot;Unable to handle kernel\nNULL pointer dereference\u0026quot; error.(CVE-2023-52863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev-\u0026gt;id value comes from ida_alloc() so it\u0026apos;s a number between zero\nand INT_MAX.  If it\u0026apos;s too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/platform: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52876)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Have trace_event_file have ref counters\r\n\r\nThe following can crash the kernel:\r\n\r\n # cd /sys/kernel/tracing\n # echo \u0026apos;p:sched schedule\u0026apos; \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026gt;events/kprobes/sched/enable\n # \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026amp;-\r\n\r\nThe above commands:\r\n\r\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn\u0026apos;t matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\r\n\r\nThe above causes a crash!\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\r\n\r\nWhat happens here is that the kprobe event creates a trace_event_file\n\u0026quot;file\u0026quot; descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the \u0026quot;enable\u0026quot; file gets a reference to the event \u0026quot;file\u0026quot; descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event \u0026quot;file\u0026quot;\ndescriptor.\r\n\r\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event \u0026quot;file\u0026quot; descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent \u0026quot;file\u0026quot; descriptor that was just freed, causing a use-after-free bug.\r\n\r\nTo solve this, add a ref count to the event \u0026quot;file\u0026quot; descriptor as well as a\nnew flag called \u0026quot;FREED\u0026quot;. The \u0026quot;file\u0026quot; will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there\u0026apos;s still a reference to the event \u0026quot;file\u0026quot; descriptor.(CVE-2023-52879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\r\n\r\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\r\n\r\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 (\u0026quot;netfilter: nf_tables: use timestamp to check for set\nelement timeout\u0026quot;).\r\n\r\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\r\n\r\nAccording to 08e4c8c5919f (\u0026quot;netfilter: nf_tables: mark newset as dead on\ntransaction abort\u0026quot;), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.(CVE-2024-26643)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: netlink: access device through ctx instead of peer\r\n\r\nThe previous commit fixed a bug that led to a NULL peer-\u0026gt;device being\ndereferenced. It\u0026apos;s actually easier and faster performance-wise to\ninstead get the device from ctx-\u0026gt;wg. This semantically makes more sense\ntoo, since ctx-\u0026gt;wg-\u0026gt;peer_allowedips.seq is compared with\nctx-\u0026gt;allowedips_seq, basing them both in ctx. This also acts as a\ndefence in depth provision against freed peers.(CVE-2024-26950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently.  If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n    kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n    kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n    kernel:  kmalloc_trace+0x3f2/0x470\n    kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]\n    kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n    kernel:  ap_device_probe+0x15c/0x290\n    kernel:  really_probe+0xd2/0x468\n    kernel:  driver_probe_device+0x40/0xf0\n    kernel:  __device_attach_driver+0xc0/0x140\n    kernel:  bus_for_each_drv+0x8c/0xd0\n    kernel:  __device_attach+0x114/0x198\n    kernel:  bus_probe_device+0xb4/0xc8\n    kernel:  device_add+0x4d2/0x6e0\n    kernel:  ap_scan_adapter+0x3d0/0x7c0\n    kernel:  ap_scan_bus+0x5a/0x3b0\n    kernel:  ap_scan_bus_wq_callback+0x40/0x60\n    kernel:  process_one_work+0x26e/0x620\n    kernel:  worker_thread+0x21c/0x440\n    kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n    kernel:  kfree+0x37e/0x418\n    kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]\n    kernel:  ap_device_remove+0x4c/0xe0\n    kernel:  device_release_driver_internal+0x1c4/0x270\n    kernel:  bus_remove_device+0x100/0x188\n    kernel:  device_del+0x164/0x3c0\n    kernel:  device_unregister+0x30/0x90\n    kernel:  ap_scan_adapter+0xc8/0x7c0\n    kernel:  ap_scan_bus+0x5a/0x3b0\n    kernel:  ap_scan_bus_wq_callback+0x40/0x60\n    kernel:  process_one_work+0x26e/0x620\n    kernel:  worker_thread+0x21c/0x440\n    kernel:  kthread+0x150/0x168\n    kernel:  __ret_from_fork+0x3c/0x58\n    kernel:  ret_from_fork+0xa/0x30\n    kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n    kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n    kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........\n    kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.\n    kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........\n    kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ\n    kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n    kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n    kernel: Call Trace:\n    kernel:  [\u0026lt;00000000ca5ab5b8\u0026gt;] dump_stack_lvl+0x90/0x120\n    kernel:  [\u0026lt;00000000c99d78bc\u0026gt;] check_bytes_and_report+0x114/0x140\n    kernel:  [\u0026lt;00000000c99d53cc\u0026gt;] check_object+0x334/0x3f8\n    kernel:  [\u0026lt;00000000c99d820c\u0026gt;] alloc_debug_processing+0xc4/0x1f8\n    kernel:  [\u0026lt;00000000c99d852e\u0026gt;] get_partial_node.part.0+0x1ee/0x3e0\n    kernel:  [\u0026lt;00000000c99d94ec\u0026gt;] ___slab_alloc+0xaf4/0x13c8\n    kernel:  [\u0026lt;00000000c99d9e38\u0026gt;] __slab_alloc.constprop.0+0x78/0xb8\n    kernel:  [\u0026lt;00000000c99dc8dc\u0026gt;] __kmalloc+0x434/0x590\n    kernel:  [\u0026lt;00000000c9b4c0ce\u0026gt;] ext4_htree_store_dirent+0x4e/0x1c0\n    kernel:  [\u0026lt;00000000c9b908a2\u0026gt;] htree_dirblock_to_tree+0x17a/0x3f0\n    kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes.  With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n  comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n  hex dump (first 32 bytes):\n    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......\u0026quot;.......\n    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n    [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n    [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n    [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n    [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n    [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n    [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n    [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n    [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n    [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n    [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n    [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n    [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n    [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n    [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n    [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\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().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: ubifs_symlink: Fix memleak of inode-\u0026gt;i_link in error path\r\n\r\nFor error handling path in ubifs_symlink(), inode will be marked as\nbad first, then iput() is invoked. If inode-\u0026gt;i_link is initialized by\nfscrypt_encrypt_symlink() in encryption scenario, inode-\u0026gt;i_link won\u0026apos;t\nbe freed by callchain ubifs_free_inode -\u0026gt; fscrypt_free_inode in error\nhandling path, because make_bad_inode() has changed \u0026apos;inode-\u0026gt;i_mode\u0026apos; as\n\u0026apos;S_IFREG\u0026apos;.\nFollowing kmemleak is easy to be reproduced by injecting error in\nubifs_jnl_update() when doing symlink in encryption scenario:\n unreferenced object 0xffff888103da3d98 (size 8):\n  comm \u0026quot;ln\u0026quot;, pid 1692, jiffies 4294914701 (age 12.045s)\n  backtrace:\n   kmemdup+0x32/0x70\n   __fscrypt_encrypt_symlink+0xed/0x1c0\n   ubifs_symlink+0x210/0x300 [ubifs]\n   vfs_symlink+0x216/0x360\n   do_symlinkat+0x11a/0x190\n   do_syscall_64+0x3b/0xe0\nThere are two ways fixing it:\n 1. Remove make_bad_inode() in error handling path. We can do that\n    because ubifs_evict_inode() will do same processes for good\n    symlink inode and bad symlink inode, for inode-\u0026gt;i_nlink checking\n    is before is_bad_inode().\n 2. Free inode-\u0026gt;i_link before marking inode bad.\nMethod 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put.  Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock.  async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  __schedule+0x33f/0xa40\n  schedule+0x53/0xc0\n  schedule_timeout+0x12a/0x140\n  __wait_for_common+0x8d/0x1d0\n  __flush_work.isra.0+0x19f/0x2c0\n  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n  kvm_put_kvm+0x1c1/0x320 [kvm]\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed.  And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue().  Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay.  kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n        trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n        __kvm_vcpu_wake_up(vcpu);\r\n\r\n        mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue.  Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n   and fill a metadata index.  It however suffers a data read error\n   and aborts, invalidating the newly returned empty metadata index.\n   It does this by setting the inode number of the index to zero,\n   which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n   read operation, locate_meta_index() returns the previous index\n   because it matches the inode number of 0.  Because this index\n   has been returned it is expected to have been filled, and because\n   it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n  Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path.  If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called).  As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(\u0026gt; 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0026apos;re using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat\u0026apos;s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it\u0026apos;s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0026apos;t play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \u0026quot;pmz: rx irq flood\u0026quot;\ndidn\u0026apos;t produce anything. So I don\u0026apos;t think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n    [   85.119255] ------------[ cut here ]------------\n    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n    [   85.151396] Hardware name: Freescale MXS (Device Tree)\n    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n    (...)\n    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n    (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\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\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967]  \u0026lt;TASK\u0026gt;\n[ 6170.287973]  ? __warn+0x9f/0x1a0\n[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092]  ? report_bug+0x1b1/0x1e0\n[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092]  ? report_bug+0x1b1/0x1e0\n[ 6170.288104]  ? handle_bug+0x3c/0x70\n[ 6170.288112]  ? exc_invalid_op+0x17/0x40\n[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn\u0026apos;t established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover normal cluster write with cp_rwsem\r\n\r\nWhen we overwrite compressed cluster w/ normal cluster, we should\nnot unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data\nwill be corrupted if partial blocks were persisted before CP \u0026amp; SPOR,\ndue to cluster metadata wasn\u0026apos;t updated atomically.(CVE-2024-27034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to guarantee persisting compressed blocks by CP\r\n\r\nIf data block in compressed cluster is not persisted with metadata\nduring checkpoint, after SPOR, the data may be corrupted, let\u0026apos;s\nguarantee to write compressed page by checkpoint.(CVE-2024-27035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix a potential buffer overflow in \u0026apos;dp_dsc_clock_en_read()\u0026apos;\r\n\r\nTell snprintf() to store at most 10 bytes in the output buffer\ninstead of 30.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands.  The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0.  While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0.  This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa-\u0026gt;data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: inode: Only d_invalidate() is needed\r\n\r\nUnloading a modular pstore backend with records in pstorefs would\ntrigger the dput() double-drop warning:\r\n\r\n  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410\r\n\r\nUsing the combo of d_drop()/dput() (as mentioned in\nDocumentation/filesystems/vfs.rst) isn\u0026apos;t the right approach here, and\nleads to the reference counting problem seen above. Use d_invalidate()\nand update the code to not bother checking for error codes that can\nnever happen.\r\n\r\n---(CVE-2024-27389)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore.  Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Keep xfd_state in sync with MSR_IA32_XFD\nCommit 672365477ae8 (\u0026quot;x86/fpu: Update XFD state where required\u0026quot;) and\ncommit 8bf26758ca96 (\u0026quot;x86/fpu: Add XFD state to fpstate\u0026quot;) introduced a\nper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in\norder to avoid unnecessary writes to the MSR.\nOn CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which\nwipes out any stale state. But the per CPU cached xfd value is not\nreset, which brings them out of sync.\nAs a consequence a subsequent xfd_update_state() might fail to update\nthe MSR which in turn can result in XRSTOR raising a #NM in kernel\nspace, which crashes the kernel.\nTo fix this, introduce xfd_set_state() to write xfd_state together\nwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag\r\n\r\nOtherwise after the GTT bo is released, the GTT and gart space is freed\nbut amdgpu_ttm_backend_unbind will not clear the gart page table entry\nand leave valid mapping entry pointing to the stale system page. Then\nif GPU access the gart address mistakely, it will read undefined value\ninstead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nLoongArch: Define the __io_aw() hook as mmiowb()\r\n\r\nCommit fb24ea52f78e0d595852e (\u0026quot;drivers: Remove explicit invocations of\nmmiowb()\u0026quot;) remove all mmiowb() in drivers, but it says:\r\n\r\n\u0026quot;NOTE: mmiowb() has only ever guaranteed ordering in conjunction with\nspin_unlock(). However, pairing each mmiowb() removal in this patch with\nthe corresponding call to spin_unlock() is not at all trivial, so there\nis a small chance that this change may regress any drivers incorrectly\nrelying on mmiowb() to order MMIO writes between CPUs using lock-free\nsynchronisation.\u0026quot;\r\n\r\nThe mmio in radeon_ring_commit() is protected by a mutex rather than a\nspinlock, but in the mutex fastpath it behaves similar to spinlock. We\ncan add mmiowb() calls in the radeon driver but the maintainer says he\ndoesn\u0026apos;t like such a workaround, and radeon is not the only example of\nmutex protected mmio.\r\n\r\nSo we should extend the mmiowb tracking system from spinlock to mutex,\nand maybe other locking primitives. This is not easy and error prone, so\nwe solve it in the architectural code, by simply defining the __io_aw()\nhook as mmiowb(). And we no longer need to override queued_spin_unlock()\nso use the generic definition.\r\n\r\nWithout this, we get such an error when run \u0026apos;glxgears\u0026apos; on weak ordering\narchitectures such as LoongArch:\r\n\r\nradeon 0000:04:00.0: ring 0 stalled for more than 10324msec\nradeon 0000:04:00.0: ring 3 stalled for more than 10240msec\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)(CVE-2024-35818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\r\n\r\nAn skb can be added to a neigh-\u0026gt;arp_queue while waiting for an arp\nreply. Where original skb\u0026apos;s skb-\u0026gt;dev can be different to neigh\u0026apos;s\nneigh-\u0026gt;dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh-\u0026gt;arp_queue of the bridge.\r\n\r\nAs skb-\u0026gt;dev can be reset back to nf_bridge-\u0026gt;physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn\u0026apos;t cleanup skbs from\ndifferent device\u0026apos;s neigh queue) we can crash on e.g. this stack:\r\n\r\narp_process\n  neigh_update\n    skb = __skb_dequeue(\u0026amp;neigh-\u0026gt;arp_queue)\n      neigh_resolve_output(..., skb)\n        ...\n          br_nf_dev_xmit\n            br_nf_pre_routing_finish_bridge_slow\n              skb-\u0026gt;dev = nf_bridge-\u0026gt;physindev\n              br_handle_frame_finish\r\n\r\nLet\u0026apos;s use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don\u0026apos;t get it and drop skb.(CVE-2024-35839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix reserve_cblocks counting error when out of space\r\n\r\nWhen a file only needs one direct_node, performing the following\noperations will cause the file to be unrepairable:\r\n\r\nunisoc # ./f2fs_io compress test.apk\nunisoc #df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.2M 100% /data\r\n\r\nunisoc # ./f2fs_io release_cblocks test.apk\n924\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 4.8M 100% /data\r\n\r\nunisoc # dd if=/dev/random of=file4 bs=1M count=3\n3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\r\n\r\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot\nunisoc # df -h  | grep dm-48\n/dev/block/dm-48             112G 112G   11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n0\r\n\r\nThis is because the file has only one direct_node. After returning\nto -ENOSPC, reserved_blocks += ret will not be executed. As a result,\nthe reserved_blocks at this time is still 0, which is not the real\nnumber of reserved blocks. Therefore, fsck cannot be set to repair\nthe file.\r\n\r\nAfter this patch, the fsck flag will be set to fix this problem.\r\n\r\nunisoc # df -h | grep dm-48\n/dev/block/dm-48             112G 112G  1.8M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot then fsck will be executed\nunisoc # df -h  | grep dm-48\n/dev/block/dm-48             112G 112G   11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n924(CVE-2024-35844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neeprom: at24: fix memory corruption race condition\r\n\r\nIf the eeprom is not accessible, an nvmem device will be registered, the\nread will fail, and the device will be torn down. If another driver\naccesses the nvmem device after the teardown, it will reference\ninvalid memory.\r\n\r\nMove the failure point before registering the nvmem device.(CVE-2024-35848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction.  [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated.  The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection.  [0]\r\n\r\n  12:01:34 executing program 3:\n  r0 = socket$nl_route(0x10, 0x3, 0x0)\n  sendmsg$nl_route(r0, ... snip ...)\n  recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3].  syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: discard table flag update with pending basechain deletion\r\n\r\nHook unregistration is deferred to the commit phase, same occurs with\nhook updates triggered by the table dormant flag. When both commands are\ncombined, this results in deleting a basechain while leaving its hook\nstill registered in the core.(CVE-2024-35897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status.  In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n  offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n  the correct offset upon a successful search, a valid chunk tree item\n  cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n  item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n  impossible to find a chunk item there due to alignment and size\n  constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/zone: Add a null pointer check to the psz_kmsg_read\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2024-35940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #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  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n  kasan_kmalloc include/linux/kasan.h:211 [inline]\n  __do_kmalloc_node mm/slub.c:3966 [inline]\n  __kmalloc+0x233/0x4a0 mm/slub.c:3979\n  kmalloc include/linux/slab.h:632 [inline]\n  __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n  set_page_owner include/linux/page_owner.h:31 [inline]\n  post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n  prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: CPPC: Use access_width over bit_width for system memory accesses\r\n\r\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\r\n\r\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n  dump_backtrace+0x0/0x1e0\n  show_stack+0x24/0x30\n  dump_stack_lvl+0x8c/0xb8\n  dump_stack+0x18/0x34\n  panic+0x16c/0x384\n  add_taint+0x0/0xc0\n  arm64_serror_panic+0x7c/0x90\n  arm64_is_fatal_ras_serror+0x34/0xa4\n  do_serror+0x50/0x6c\n  el1h_64_error_handler+0x40/0x74\n  el1h_64_error+0x7c/0x80\n  cppc_get_perf_caps+0xec/0x410\n  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n  cpufreq_online+0x2dc/0xa30\n  cpufreq_add_dev+0xc0/0xd4\n  subsys_interface_register+0x134/0x14c\n  cpufreq_register_driver+0x1b0/0x354\n  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n  do_one_initcall+0x50/0x250\n  do_init_module+0x60/0x27c\n  load_module+0x2300/0x2570\n  __do_sys_finit_module+0xa8/0x114\n  __arm64_sys_finit_module+0x2c/0x3c\n  invoke_syscall+0x78/0x100\n  el0_svc_common.constprop.0+0x180/0x1a0\n  do_el0_svc+0x84/0xa0\n  el0_svc+0x2c/0xc0\n  el0t_64_sync_handler+0xa4/0x12c\n  el0t_64_sync+0x1a4/0x1a8\r\n\r\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\r\n\r\nIf access_width is not set, then fall back to using bit_width.\r\n\r\n[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix incorrect list API usage\r\n\r\nBoth the function that migrates all the chunks within a region and the\nfunction that migrates all the entries within a chunk call\nlist_first_entry() on the respective lists without checking that the\nlists are not empty. This is incorrect usage of the API, which leads to\nthe following warning [1].\r\n\r\nFix by returning if the lists are empty as there is nothing to migrate\nin this case.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0\u0026gt;\nModules linked in:\nCPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-36006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv4: check for NULL idev in ip_route_use_hint()\r\n\r\nsyzbot was able to trigger a NULL deref in fib_validate_source()\nin an old tree [1].\r\n\r\nIt appears the bug exists in latest trees.\r\n\r\nAll calls to __in_dev_get_rcu() must be checked for a NULL result.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425\nCode: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf\nRSP: 0018:ffffc900015fee40 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0\nRDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0\nRBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000\nR10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000\nFS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n  ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231\n  ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327\n  ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]\n  ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638\n  ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673\n  __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]\n  __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620\n  __netif_receive_skb_list net/core/dev.c:5672 [inline]\n  netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764\n  netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816\n  xdp_recv_frames net/bpf/test_run.c:257 [inline]\n  xdp_test_run_batch net/bpf/test_run.c:335 [inline]\n  bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363\n  bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376\n  bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736\n  __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115\n  __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]\n  __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]\n  __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)",
  "id": "OESA-2024-1682",
  "modified": "2026-08-06T11:07:08Z",
  "published": "2024-05-31T11:07:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1682"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47421"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48645"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52650"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52652"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52653"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52656"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52683"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52805"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52840"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52845"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52847"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52854"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52869"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52876"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26643"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26957"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26993"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26994"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27000"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27024"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27034"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27037"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27045"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27073"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27075"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27388"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27389"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27403"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27407"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27419"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27426"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27427"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27428"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35801"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35848"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35897"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36008"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47421",
    "CVE-2021-47455",
    "CVE-2022-48645",
    "CVE-2023-52650",
    "CVE-2023-52652",
    "CVE-2023-52653",
    "CVE-2023-52656",
    "CVE-2023-52664",
    "CVE-2023-52674",
    "CVE-2023-52683",
    "CVE-2023-52698",
    "CVE-2023-52804",
    "CVE-2023-52805",
    "CVE-2023-52809",
    "CVE-2023-52817",
    "CVE-2023-52818",
    "CVE-2023-52835",
    "CVE-2023-52840",
    "CVE-2023-52844",
    "CVE-2023-52845",
    "CVE-2023-52846",
    "CVE-2023-52847",
    "CVE-2023-52854",
    "CVE-2023-52858",
    "CVE-2023-52863",
    "CVE-2023-52867",
    "CVE-2023-52868",
    "CVE-2023-52869",
    "CVE-2023-52876",
    "CVE-2023-52879",
    "CVE-2024-26643",
    "CVE-2024-26950",
    "CVE-2024-26955",
    "CVE-2024-26957",
    "CVE-2024-26958",
    "CVE-2024-26961",
    "CVE-2024-26965",
    "CVE-2024-26972",
    "CVE-2024-26976",
    "CVE-2024-26982",
    "CVE-2024-26993",
    "CVE-2024-26994",
    "CVE-2024-26999",
    "CVE-2024-27000",
    "CVE-2024-27008",
    "CVE-2024-27010",
    "CVE-2024-27011",
    "CVE-2024-27024",
    "CVE-2024-27034",
    "CVE-2024-27035",
    "CVE-2024-27037",
    "CVE-2024-27045",
    "CVE-2024-27059",
    "CVE-2024-27072",
    "CVE-2024-27073",
    "CVE-2024-27075",
    "CVE-2024-27388",
    "CVE-2024-27389",
    "CVE-2024-27403",
    "CVE-2024-27407",
    "CVE-2024-27419",
    "CVE-2024-27426",
    "CVE-2024-27427",
    "CVE-2024-27428",
    "CVE-2024-35801",
    "CVE-2024-35805",
    "CVE-2024-35806",
    "CVE-2024-35815",
    "CVE-2024-35817",
    "CVE-2024-35818",
    "CVE-2024-35835",
    "CVE-2024-35839",
    "CVE-2024-35844",
    "CVE-2024-35848",
    "CVE-2024-35886",
    "CVE-2024-35897",
    "CVE-2024-35898",
    "CVE-2024-35922",
    "CVE-2024-35930",
    "CVE-2024-35936",
    "CVE-2024-35940",
    "CVE-2024-35976",
    "CVE-2024-35995",
    "CVE-2024-35997",
    "CVE-2024-36006",
    "CVE-2024-36008"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.88.0.169.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.88.0.169.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.88.0.169.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\ns390/qeth: fix deadlock during failing recovery\r\n\r\nCommit 0b9902c1fcc5 (\u0026quot;s390/qeth: fix deadlock during recovery\u0026quot;) removed\ntaking discipline_mutex inside qeth_do_reset(), fixing potential\ndeadlocks. An error path was missed though, that still takes\ndiscipline_mutex and thus has the original deadlock potential.\r\n\r\nIntermittent deadlocks were seen when a qeth channel path is configured\noffline, causing a race between qeth_do_reset and ccwgroup_remove.\nCall qeth_set_offline() directly in the qeth_do_reset() error case and\nthen a new variant of ccwgroup_set_offline(), without taking\ndiscipline_mutex.(CVE-2021-47382)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()\r\n\r\nEnsure the value passed to scarlett2_mixer_ctl_put() is between 0 and\nSCARLETT2_MIXER_MAX_VALUE so we don\u0026apos;t attempt to access outside\nscarlett2_mixer_values[].(CVE-2023-52674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\r\n\r\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type \u0026apos;int\u0026apos;\r\n\r\nWhen the value of the variable \u0026quot;sd-\u0026gt;params.exposure.gain\u0026quot; exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable \u0026quot;currentexp\u0026quot; cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.(CVE-2023-52764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new\r\n\r\nThis patch enhances error handling in scenarios with RTS (Request to\nSend) messages arriving closely. It replaces the less informative WARN_ON_ONCE\nbacktraces with a new error handling method. This provides clearer error\nmessages and allows for the early termination of problematic sessions.\nPreviously, sessions were only released at the end of j1939_xtp_rx_rts().\r\n\r\nPotentially this could be reproduced with something like:\ntestj1939 -r vcan0:0x80 \u0026amp;\nwhile true; do\n\t# send first RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send second RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send abort\n\tcansend vcan0 18EC8090#ff00000000002301;\ndone(CVE-2023-52887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: Dont Use skb-\u0026gt;sk in ipvlan_process_v{4,6}_outbound\r\n\r\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\r\n\r\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n ? __warn (kernel/panic.c:693)\n ? sk_mc_loop (net/core/sock.c:760)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:239)\n ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? sk_mc_loop (net/core/sock.c:760)\n ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n ? nf_hook_slow (net/netfilter/core.c:626)\n ip6_finish_output (net/ipv6/ip6_output.c:222)\n ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\n ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\n ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\n dev_hard_start_xmit (net/core/dev.c:3594)\n sch_direct_xmit (net/sched/sch_generic.c:343)\n __qdisc_run (net/sched/sch_generic.c:416)\n net_tx_action (net/core/dev.c:5286)\n handle_softirqs (kernel/softirq.c:555)\n __irq_exit_rcu (kernel/softirq.c:589)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\r\n\r\nThe warning triggers as this:\npacket_sendmsg\n   packet_snd //skb-\u0026gt;sk is packet sk\n      __dev_queue_xmit\n         __dev_xmit_skb //q-\u0026gt;enqueue is not NULL\n             __qdisc_run\n               sch_direct_xmit\n                 dev_hard_start_xmit\n                   ipvlan_start_xmit\n                      ipvlan_xmit_mode_l3 //l3 mode\n                        ipvlan_process_outbound //vepa flag\n                          ipvlan_process_v6_outbound\n                            ip6_local_out\n                                __ip6_finish_output\n                                  ip6_finish_output2 //multicast packet\n                                    sk_mc_loop //sk-\u0026gt;sk_family is AF_PACKET\r\n\r\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux: avoid dereference of garbage after mount failure\r\n\r\nIn case kern_mount() fails and returns an error pointer return in the\nerror branch instead of continuing and dereferencing the error pointer.\r\n\r\nWhile on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: vc4: Fix possible null pointer dereference\r\n\r\nIn vc4_hdmi_audio_init() of_get_address() may return\nNULL which is later dereferenced. Fix this bug by adding NULL check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkunit: Fix kthread reference\r\n\r\nThere is a race condition when a kthread finishes after the deadline and\nbefore the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: move the EST lock to struct stmmac_priv\r\n\r\nReinitialize the whole EST structure would also reset the mutex\nlock which is embedded in the EST structure, and then trigger\nthe following warning. To address this, move the lock to struct\nstmmac_priv. We also need to reacquire the mutex lock when doing\nthis initialization.\r\n\r\nDEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\nWARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068\n Modules linked in:\n CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29\n Hardware name: NXP i.MX8MPlus EVK board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __mutex_lock+0xd84/0x1068\n lr : __mutex_lock+0xd84/0x1068\n sp : ffffffc0864e3570\n x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003\n x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac\n x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff\n x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000\n x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8\n x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698\n x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001\n x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  __mutex_lock+0xd84/0x1068\n  mutex_lock_nested+0x28/0x34\n  tc_setup_taprio+0x118/0x68c\n  stmmac_setup_tc+0x50/0xf0\n  taprio_change+0x868/0xc9c(CVE-2024-38594)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstm class: Fix a double free in stm_register_device()\r\n\r\nThe put_device(\u0026amp;stm-\u0026gt;dev) call will trigger stm_device_release() which\nfrees \u0026quot;stm\u0026quot; so the vfree(stm) on the next line is a double free.(CVE-2024-38627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: add error handle to avoid out-of-bounds\r\n\r\nif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should\nbe stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)\r\n\r\nLack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap\nallows users to call mmap with PROT_WRITE and MAP_PRIVATE flag\ncausing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:\nBUG_ON((vma-\u0026gt;vm_flags \u0026amp; VM_PFNMAP) \u0026amp;\u0026amp; is_cow_mapping(vma-\u0026gt;vm_flags));\r\n\r\nReturn -EINVAL early if COW mapping is detected.\r\n\r\nThis bug affects all drm drivers using default shmem helpers.\nIt can be reproduced by this simple example:\nvoid *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);\nptr[0] = 0;(CVE-2024-39497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix refcount imbalance on inbound connections\r\n\r\nWhen releasing a socket in ax25_release(), we call netdev_put() to\ndecrease the refcount on the associated ax.25 device. However, the\nexecution path for accepting an incoming connection never calls\nnetdev_hold(). This imbalance leads to refcount errors, and ultimately\nto kernel crashes.\r\n\r\nA typical call trace for the above situation will start with one of the\nfollowing errors:\r\n\r\n    refcount_t: decrement hit 0; leaking memory.\n    refcount_t: underflow; use-after-free.\r\n\r\nAnd will then have a trace like:\r\n\r\n    Call Trace:\n    \u0026lt;TASK\u0026gt;\n    ? show_regs+0x64/0x70\n    ? __warn+0x83/0x120\n    ? refcount_warn_saturate+0xb2/0x100\n    ? report_bug+0x158/0x190\n    ? prb_read_valid+0x20/0x30\n    ? handle_bug+0x3e/0x70\n    ? exc_invalid_op+0x1c/0x70\n    ? asm_exc_invalid_op+0x1f/0x30\n    ? refcount_warn_saturate+0xb2/0x100\n    ? refcount_warn_saturate+0xb2/0x100\n    ax25_release+0x2ad/0x360\n    __sock_release+0x35/0xa0\n    sock_close+0x19/0x20\n    [...]\r\n\r\nOn reboot (or any attempt to remove the interface), the kernel gets\nstuck in an infinite loop:\r\n\r\n    unregister_netdevice: waiting for ax0 to become free. Usage count = 0\r\n\r\nThis patch corrects these issues by ensuring that we call netdev_hold()\nand ax25_dev_hold() for new connections in ax25_accept(). This makes the\nlogic leading to ax25_accept() match the logic for ax25_bind(): in both\ncases we increment the refcount, which is ultimately decremented in\nax25_release().(CVE-2024-40910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()\r\n\r\nUse {READ,WRITE}_ONCE() to access kvm-\u0026gt;last_boosted_vcpu to ensure the\nloads and stores are atomic.  In the extremely unlikely scenario the\ncompiler tears the stores, it\u0026apos;s theoretically possible for KVM to attempt\nto get a vCPU using an out-of-bounds index, e.g. if the write is split\ninto multiple 8-bit stores, and is paired with a 32-bit load on a VM with\n257 vCPUs:\r\n\r\n  CPU0                              CPU1\n  last_boosted_vcpu = 0xff;\r\n\r\n                                    (last_boosted_vcpu = 0x100)\n                                    last_boosted_vcpu[15:8] = 0x01;\n  i = (last_boosted_vcpu = 0x1ff)\n                                    last_boosted_vcpu[7:0] = 0x00;\r\n\r\n  vcpu = kvm-\u0026gt;vcpu_array[0x1ff];\r\n\r\nAs detected by KCSAN:\r\n\r\n  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]\r\n\r\n  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:\n  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm\n  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel\n  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?\n\t\t arch/x86/kvm/vmx/vmx.c:6606) kvm_intel\n  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm\n  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm\n  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm\n  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)\n  __x64_sys_ioctl (fs/ioctl.c:890)\n  x64_sys_call (arch/x86/entry/syscall_64.c:33)\n  do_syscall_64 (arch/x86/entry/common.c:?)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n  read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:\n  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm\n  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel\n  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?\n\t\t\tarch/x86/kvm/vmx/vmx.c:6606) kvm_intel\n  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm\n  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm\n  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm\n  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)\n  __x64_sys_ioctl (fs/ioctl.c:890)\n  x64_sys_call (arch/x86/entry/syscall_64.c:33)\n  do_syscall_64 (arch/x86/entry/common.c:?)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n  value changed: 0x00000012 -\u0026gt; 0x00000000(CVE-2024-40953)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\r\n\r\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\r\n\r\nsyzbot reported:\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL deref in fib6_nh_init()\r\n\r\nsyzbot reminds us that in6_dev_get() can return NULL.\r\n\r\nfib6_nh_init()\n    ip6_validate_gw(  \u0026amp;idev  )\n        ip6_route_check_nh(  idev  )\n            *idev = in6_dev_get(dev); // can be NULL\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: mask irqs in timeout path before hard reset\r\n\r\nThere is a race condition in which a rendering job might take just long\nenough to trigger the drm sched job timeout handler but also still\ncomplete before the hard reset is done by the timeout handler.\nThis runs into race conditions not expected by the timeout handler.\nIn some very specific cases it currently may result in a refcount\nimbalance on lima_pm_idle, with a stack dump such as:\r\n\r\n[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669628] Call trace:\n[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0\n[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0\n[10136.669656]  lima_gp_irq_handler+0xa8/0x120\n[10136.669666]  __handle_irq_event_percpu+0x48/0x160\n[10136.669679]  handle_irq_event+0x4c/0xc0\r\n\r\nWe can prevent that race condition entirely by masking the irqs at the\nbeginning of the timeout handler, at which point we give up on waiting\nfor that job entirely.\nThe irqs will be enabled again at the next hard reset which is already\ndone as a recovery by the timeout handler.(CVE-2024-40976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nssb: Fix potential NULL pointer dereference in ssb_device_uevent()\r\n\r\nThe ssb_device_uevent() function first attempts to convert the \u0026apos;dev\u0026apos; pointer\nto \u0026apos;struct ssb_device *\u0026apos;. However, it mistakenly dereferences \u0026apos;dev\u0026apos; before\nperforming the NULL check, potentially leading to a NULL pointer\ndereference if \u0026apos;dev\u0026apos; is NULL.\r\n\r\nTo fix this issue, move the NULL check before dereferencing the \u0026apos;dev\u0026apos; pointer,\nensuring that the pointer is valid before attempting to use it.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Add validation for completion descriptors consistency\r\n\r\nValidate that `first` flag is set only for the first\ndescriptor in multi-buffer packets.\nIn case of an invalid descriptor, a reset will occur.\nA new reset reason for RX data corruption has been added.(CVE-2024-40999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfs: don\u0026apos;t walk off the end of a directory data block\r\n\r\nThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry\nto make sure don\u0026apos;t stray beyond valid memory region. Before patching, the\nloop simply checks that the start offset of the dup and dep is within the\nrange. So in a crafted image, if last entry is xfs_dir2_data_unused, we\ncan change dup-\u0026gt;length to dup-\u0026gt;length-1 and leave 1 byte of space. In the\nnext traversal, this space will be considered as dup or dep. We may\nencounter an out of bound read when accessing the fixed members.\r\n\r\nIn the patch, we make sure that the remaining bytes large enough to hold\nan unused entry before accessing xfs_dir2_data_unused and\nxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make\nsure that the remaining bytes large enough to hold a dirent with a\nsingle-byte name before accessing xfs_dir2_data_entry.(CVE-2024-41013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfs: add bounds checking to xlog_recover_process_data\r\n\r\nThere is a lack of verification of the space occupied by fixed members\nof xlog_op_header in the xlog_recover_process_data.\r\n\r\nWe can create a crafted image to trigger an out of bounds read by\nfollowing these steps:\n    1) Mount an image of xfs, and do some file operations to leave records\n    2) Before umounting, copy the image for subsequent steps to simulate\n       abnormal exit. Because umount will ensure that tail_blk and\n       head_blk are the same, which will result in the inability to enter\n       xlog_recover_process_data\n    3) Write a tool to parse and modify the copied image in step 2\n    4) Make the end of the xlog_op_header entries only 1 byte away from\n       xlog_rec_header-\u0026gt;h_size\n    5) xlog_rec_header-\u0026gt;h_num_logops++\n    6) Modify xlog_rec_header-\u0026gt;h_crc\r\n\r\nFix:\nAdd a check to make sure there is sufficient space to access fixed members\nof xlog_op_header.(CVE-2024-41014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Validate ff offset\r\n\r\nThis adds sanity checks for ff offset. There is a check\non rt-\u0026gt;first_free at first, but walking through by ff\nwithout any check. If the second ff is a large offset.\nWe may encounter an out-of-bound read.(CVE-2024-41019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Fix fcntl/close race recovery compat path\r\n\r\nWhen I wrote commit 3cad1bc01041 (\u0026quot;filelock: Remove locks reliably when\nfcntl/close race is detected\u0026quot;), I missed that there are two copies of the\ncode I was patching: The normal version, and the version for 64-bit offsets\non 32-bit kernels.\nThanks to Greg KH for stumbling over this while doing the stable\nbackport...\r\n\r\nApply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()\r\n\r\nThe \u0026quot;instance\u0026quot; variable needs to be signed for the error handling to work.(CVE-2024-41022)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/deadline: Fix task_struct reference leak\r\n\r\nDuring the execution of the following stress test with linux-rt:\r\n\r\nstress-ng --cyclic 30 --timeout 30 --minimize --quiet\r\n\r\nkmemleak frequently reported a memory leak concerning the task_struct:\r\n\r\nunreferenced object 0xffff8881305b8000 (size 16136):\n  comm \u0026quot;stress-ng\u0026quot;, pid 614, jiffies 4294883961 (age 286.412s)\n  object hex dump (first 32 bytes):\n    02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  debug hex dump (first 16 bytes):\n    53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............\n  backtrace:\n    [\u0026lt;00000000046b6790\u0026gt;] dup_task_struct+0x30/0x540\n    [\u0026lt;00000000c5ca0f0b\u0026gt;] copy_process+0x3d9/0x50e0\n    [\u0026lt;00000000ced59777\u0026gt;] kernel_clone+0xb0/0x770\n    [\u0026lt;00000000a50befdc\u0026gt;] __do_sys_clone+0xb6/0xf0\n    [\u0026lt;000000001dbf2008\u0026gt;] do_syscall_64+0x5d/0xf0\n    [\u0026lt;00000000552900ff\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nThe issue occurs in start_dl_timer(), which increments the task_struct\nreference count and sets a timer. The timer callback, dl_task_timer,\nis supposed to decrement the reference count upon expiration. However,\nif enqueue_task_dl() is called before the timer expires and cancels it,\nthe reference count is not decremented, leading to the leak.\r\n\r\nThis patch fixes the reference leak by ensuring the task_struct\nreference count is properly decremented when the timer is canceled.(CVE-2024-41023)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nFix userfaultfd_api to return EINVAL as expected\r\n\r\nCurrently if we request a feature that is not set in the Kernel config we\nfail silently and return all the available features.  However, the man\npage indicates we should return an EINVAL.\r\n\r\nWe need to fix this issue since we can end up with a Kernel warning should\na program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with\nthe config not set with this feature.\r\n\r\n [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660\n [  200.820738] Modules linked in:\n [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8\n [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022\n [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660(CVE-2024-41027)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix UAF when resolving a clash\r\n\r\nKASAN reports the following UAF:\r\n\r\n BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n Read of size 1 at addr ffff888c07603600 by task handler130/6469\r\n\r\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  dump_stack_lvl+0x48/0x70\n  print_address_description.constprop.0+0x33/0x3d0\n  print_report+0xc0/0x2b0\n  kasan_report+0xd0/0x120\n  __asan_load1+0x6c/0x80\n  tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n  tcf_ct_act+0x886/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\n  __irq_exit_rcu+0x82/0xc0\n  irq_exit_rcu+0xe/0x20\n  common_interrupt+0xa1/0xb0\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  asm_common_interrupt+0x27/0x40\r\n\r\n Allocated by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_alloc_info+0x1e/0x40\n  __kasan_krealloc+0x133/0x190\n  krealloc+0xaa/0x130\n  nf_ct_ext_add+0xed/0x230 [nf_conntrack]\n  tcf_ct_act+0x1095/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\n Freed by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_free_info+0x2b/0x60\n  ____kasan_slab_free+0x180/0x1f0\n  __kasan_slab_free+0x12/0x30\n  slab_free_freelist_hook+0xd2/0x1a0\n  __kmem_cache_free+0x1a2/0x2f0\n  kfree+0x78/0x120\n  nf_conntrack_free+0x74/0x130 [nf_conntrack]\n  nf_ct_destroy+0xb2/0x140 [nf_conntrack]\n  __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]\n  nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]\n  __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]\n  tcf_ct_act+0x12ad/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\nThe ct may be dropped if a clash has been resolved but is still passed to\nthe tcf_ct_flow_table_process_conn function for further usage. This issue\ncan be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().\r\n\r\nsyzkaller triggered the warning [0] in udp_v4_early_demux().\r\n\r\nIn udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount\nof the looked-up sk and use sock_pfree() as skb-\u0026gt;destructor, so we check\nSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace\nperiod.\r\n\r\nCurrently, SOCK_RCU_FREE is flagged for a bound socket after being put\ninto the hash table.  Moreover, the SOCK_RCU_FREE check is done too early\nin udp_v[46]_early_demux() and sk_lookup(), so there could be a small race\nwindow:\r\n\r\n  CPU1                                 CPU2\n  ----                                 ----\n  udp_v4_early_demux()                 udp_lib_get_port()\n  |                                    |- hlist_add_head_rcu()\n  |- sk = __udp4_lib_demux_lookup()    |\n  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));\n                                       `- sock_set_flag(sk, SOCK_RCU_FREE)\r\n\r\nWe had the same bug in TCP and fixed it in commit 871019b22d1b (\u0026quot;net:\nset SOCK_RCU_FREE before inserting socket into hashtable\u0026quot;).\r\n\r\nLet\u0026apos;s apply the same fix for UDP.\r\n\r\n[0]:\nWARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nModules linked in:\nCPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nCode: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe \u0026lt;0f\u0026gt; 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52\nRSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c\nRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001\nRBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680\nR13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e\nFS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349\n ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624\n __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738\n netif_receive_skb_internal net/core/dev.c:5824 [inline]\n netif_receive_skb+0x271/0x300 net/core/dev.c:5884\n tun_rx_batched drivers/net/tun.c:1549 [inline]\n tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002\n tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x76f/0x8d0 fs/read_write.c:590\n ksys_write+0xbf/0x190 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x41/0x50 fs/read_write.c:652\n x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fc44a68bc1f\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48\nRSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f\nR\n---truncated---(CVE-2024-41041)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppp: reject claimed-as-LCP but actually malformed packets\r\n\r\nSince \u0026apos;ppp_async_encode()\u0026apos; assumes valid LCP packets (with code\nfrom 1 to 7 inclusive), add \u0026apos;ppp_check_packet()\u0026apos; to ensure that\nLCP packet has an actual body beyond PPP_LCP header bytes, and\nreject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nskmsg: Skip zero length skb in sk_msg_recvmsg\r\n\r\nWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch\nplatform, the following kernel panic occurs:\r\n\r\n  [...]\n  Oops[#1]:\n  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18\n  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018\n     ... ...\n     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560\n    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0\n   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n   PRMD: 0000000c (PPLV0 +PIE +PWE)\n   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n   BADV: 0000000000000040\n   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)\n  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack\n  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)\n  Stack : ...\n  Call Trace:\n  [\u0026lt;9000000004162774\u0026gt;] copy_page_to_iter+0x74/0x1c0\n  [\u0026lt;90000000048bf6c0\u0026gt;] sk_msg_recvmsg+0x120/0x560\n  [\u0026lt;90000000049f2b90\u0026gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0\n  [\u0026lt;90000000049aae34\u0026gt;] inet_recvmsg+0x54/0x100\n  [\u0026lt;900000000481ad5c\u0026gt;] sock_recvmsg+0x7c/0xe0\n  [\u0026lt;900000000481e1a8\u0026gt;] __sys_recvfrom+0x108/0x1c0\n  [\u0026lt;900000000481e27c\u0026gt;] sys_recvfrom+0x1c/0x40\n  [\u0026lt;9000000004c076ec\u0026gt;] do_syscall+0x8c/0xc0\n  [\u0026lt;9000000003731da4\u0026gt;] handle_syscall+0xc4/0x160\n  Code: ...\n  ---[ end trace 0000000000000000 ]---\n  Kernel panic - not syncing: Fatal exception\n  Kernel relocated by 0x3510000\n   .text @ 0x9000000003710000\n   .data @ 0x9000000004d70000\n   .bss  @ 0x9000000006469400\n  ---[ end Kernel panic - not syncing: Fatal exception ]---\n  [...]\r\n\r\nThis crash happens every time when running sockmap_skb_verdict_shutdown\nsubtest in sockmap_basic.\r\n\r\nThis crash is because a NULL pointer is passed to page_address() in the\nsk_msg_recvmsg(). Due to the different implementations depending on the\narchitecture, page_address(NULL) will trigger a panic on Loongarch\nplatform but not on x86 platform. So this bug was hidden on x86 platform\nfor a while, but now it is exposed on Loongarch platform. The root cause\nis that a zero length skb (skb-\u0026gt;len == 0) was put on the queue.\r\n\r\nThis zero length skb is a TCP FIN packet, which was sent by shutdown(),\ninvoked in test_sockmap_skb_verdict_shutdown():\r\n\r\n\tshutdown(p1, SHUT_WR);\r\n\r\nIn this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no\npage is put to this sge (see sg_set_page in sg_set_page), but this empty\nsge is queued into ingress_msg list.\r\n\r\nAnd in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by\nsg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it\nto kmap_local_page() and to page_address(), then kernel panics.\r\n\r\nTo solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),\nif copy is zero, that means it\u0026apos;s a zero length skb, skip invoking\ncopy_page_to_iter(). We are using the EFAULT return triggered by\ncopy_page_to_iter to check for is_fin in tcp_bpf.c.(CVE-2024-41048)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbluetooth/l2cap: sync sock recv cb and release\r\n\r\nThe problem occurs between the system call to close the sock and hci_rx_work,\nwhere the former releases the sock and the latter accesses it without lock protection.\r\n\r\n           CPU0                       CPU1\n           ----                       ----\n           sock_close                 hci_rx_work\n\t   l2cap_sock_release         hci_acldata_packet\n\t   l2cap_sock_kill            l2cap_recv_frame\n\t   sk_free                    l2cap_conless_channel\n\t                              l2cap_sock_recv_cb\r\n\r\nIf hci_rx_work processes the data that needs to be received before the sock is\nclosed, then everything is normal; Otherwise, the work thread may access the\nreleased sock when receiving data.\r\n\r\nAdd a chan mutex in the rx callback of the sock to achieve synchronization between\nthe sock release and recv cb.\r\n\r\nSock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_core: cancel all works upon hci_unregister_dev()\r\n\r\nsyzbot is reporting that calling hci_release_dev() from hci_error_reset()\ndue to hci_dev_put() from hci_error_reset() can cause deadlock at\ndestroy_workqueue(), for hci_error_reset() is called from\nhdev-\u0026gt;req_workqueue which destroy_workqueue() needs to flush.\r\n\r\nWe need to make sure that hdev-\u0026gt;{rx_work,cmd_work,tx_work} which are\nqueued into hdev-\u0026gt;workqueue and hdev-\u0026gt;{power_on,error_reset} which are\nqueued into hdev-\u0026gt;req_workqueue are no longer running by the moment\r\n\r\n       destroy_workqueue(hdev-\u0026gt;workqueue);\n       destroy_workqueue(hdev-\u0026gt;req_workqueue);\r\n\r\nare called from hci_release_dev().\r\n\r\nCall cancel_work_sync() on these work items from hci_unregister_dev()\nas soon as hdev-\u0026gt;list is removed from hci_dev_list.(CVE-2024-41063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/eeh: avoid possible crash when edev-\u0026gt;pdev changes\r\n\r\nIf a PCI device is removed during eeh_pe_report_edev(), edev-\u0026gt;pdev\nwill change and can cause a crash, hold the PCI rescan/remove lock\nwhile taking a copy of edev-\u0026gt;pdev-\u0026gt;bus.(CVE-2024-41064)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: topology: Fix references to freed memory\r\n\r\nMost users after parsing a topology file, release memory used by it, so\nhaving pointer references directly into topology file contents is wrong.\nUse devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()\r\n\r\nAl reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().\r\n\r\nIt looks up `stt` from tablefd, but then continues to use it after doing\nfdput() on the returned fd. After the fdput() the tablefd is free to be\nclosed by another thread. The close calls kvm_spapr_tce_release() and\nthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.\r\n\r\nAlthough there are calls to rcu_read_lock() in\nkvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent\nthe UAF, because `stt` is used outside the locked regions.\r\n\r\nWith an artifcial delay after the fdput() and a userspace program which\ntriggers the race, KASAN detects the UAF:\r\n\r\n  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505\n  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1\n  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\n  Call Trace:\n    dump_stack_lvl+0xb4/0x108 (unreliable)\n    print_report+0x2b4/0x6ec\n    kasan_report+0x118/0x2b0\n    __asan_load4+0xb8/0xd0\n    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n    kvm_vfio_set_attr+0x524/0xac0 [kvm]\n    kvm_device_ioctl+0x144/0x240 [kvm]\n    sys_ioctl+0x62c/0x1810\n    system_call_exception+0x190/0x440\n    system_call_vectored_common+0x15c/0x2ec\n  ...\n  Freed by task 0:\n   ...\n   kfree+0xec/0x3e0\n   release_spapr_tce_table+0xd4/0x11c [kvm]\n   rcu_core+0x568/0x16a0\n   handle_softirqs+0x23c/0x920\n   do_softirq_own_stack+0x6c/0x90\n   do_softirq_own_stack+0x58/0x90\n   __irq_exit_rcu+0x218/0x2d0\n   irq_exit+0x30/0x80\n   arch_local_irq_restore+0x128/0x230\n   arch_local_irq_enable+0x1c/0x30\n   cpuidle_enter_state+0x134/0x5cc\n   cpuidle_enter+0x6c/0xb0\n   call_cpuidle+0x7c/0x100\n   do_idle+0x394/0x410\n   cpu_startup_entry+0x60/0x70\n   start_secondary+0x3fc/0x410\n   start_secondary_prolog+0x10/0x14\r\n\r\nFix it by delaying the fdput() until `stt` is no longer in use, which\nis effectively the entire function. To keep the patch minimal add a call\nto fdput() at each of the existing return paths. Future work can convert\nthe function to goto or __cleanup style cleanup.\r\n\r\nWith the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: wext: add extra SIOCSIWSCAN data check\r\n\r\nIn \u0026apos;cfg80211_wext_siwscan()\u0026apos;, add extra check whether number of\nchannels passed via \u0026apos;ioctl(sock, SIOCSIWSCAN, ...)\u0026apos; doesn\u0026apos;t exceed\nIW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix validation of block size\r\n\r\nBlock size should be between 512 and PAGE_SIZE and be a power of 2. The current\ncheck does not validate this, so update the check.\r\n\r\nWithout this patch, null_blk would Oops due to a null pointer deref when\nloaded with bs=1536 [1].\r\n\r\n\n[axboe: remove unnecessary braces and != 0 check](CVE-2024-41077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: always initialize cqe.result\r\n\r\nThe spec doesn\u0026apos;t mandate that the first two double words (aka results)\nfor the command queue entry need to be set to 0 when they are not\nused (not specified). Though, the target implemention returns 0 for TCP\nand FC but not for RDMA.\r\n\r\nLet\u0026apos;s make RDMA behave the same and thus explicitly initializing the\nresult field. This prevents leaking any data from the stack.(CVE-2024-41079)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: fix possible deadlock in io_register_iowq_max_workers()\r\n\r\nThe io_register_iowq_max_workers() function calls io_put_sq_data(),\nwhich acquires the sqd-\u0026gt;lock without releasing the uring_lock.\nSimilar to the commit 009ad9f0c6ee (\u0026quot;io_uring: drop ctx-\u0026gt;uring_lock\nbefore acquiring sqd-\u0026gt;lock\u0026quot;), this can lead to a potential deadlock\nsituation.\r\n\r\nTo resolve this issue, the uring_lock is released before calling\nio_put_sq_data(), and then it is re-acquired after the function call.\r\n\r\nThis change ensures that the locks are acquired in the correct\norder, preventing the possibility of a deadlock.(CVE-2024-41080)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nila: block BH in ila_output()\r\n\r\nAs explained in commit 1378817486d6 (\u0026quot;tipc: block BH\nbefore using dst_cache\u0026quot;), net/core/dst_cache.c\nhelpers need to be called with BH disabled.\r\n\r\nila_output() is called from lwtunnel_output()\npossibly from process context, and under rcu_read_lock().\r\n\r\nWe might be interrupted by a softirq, re-enter ila_output()\nand corrupt dst_cache data structures.\r\n\r\nFix the race by using local_bh_disable().(CVE-2024-41081)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes\r\n\r\nIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().\nAdd a check to avoid null pointer dereference.(CVE-2024-41089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntap: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tap_get_user_xdp() path, which could cause a corrupted skb to be\nsent downstack. Even before the skb is transmitted, the\ntap_get_user_xdp()--\u0026gt;skb_set_network_header() may assume the size is more\nthan ETH_HLEN. Once transmitted, this could either cause out-of-bound\naccess beyond the actual length, or confuse the underlayer with incorrect\nor inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tap_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tap_get_user() does.\r\n\r\nCVE: CVE-2024-41090(CVE-2024-41090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tun_xdp_one() path, which could cause a corrupted skb to be sent\ndownstack. Even before the skb is transmitted, the\ntun_xdp_one--\u0026gt;eth_type_trans() may access the Ethernet header although it\ncan be less than ETH_HLEN. Once transmitted, this could either cause\nout-of-bound access beyond the actual length, or confuse the underlayer\nwith incorrect or inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tun_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted for\nIFF_TAP.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tun_get_user() does.\r\n\r\nCVE: CVE-2024-41091(CVE-2024-41091)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: atm: cxacru: fix endpoint checking in cxacru_bind()\r\n\r\nSyzbot is still reporting quite an old issue [1] that occurs due to\nincomplete checking of present usb endpoints. As such, wrong\nendpoints types may be used at urb sumbitting stage which in turn\ntriggers a warning in usb_submit_urb().\r\n\r\nFix the issue by verifying that required endpoint types are present\nfor both in and out endpoints, taking into account cmd endpoint type.\r\n\r\nUnfortunately, this patch has not been tested on real hardware.\r\n\r\n[1] Syzbot report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\n...\nCall Trace:\n cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649\n cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760\n cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209\n usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055\n cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363\n usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:517 [inline]\n really_probe+0x23c/0xcd0 drivers/base/dd.c:595\n __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777\n __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894\n bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427\n __device_attach+0x228/0x4a0 drivers/base/dd.c:965\n bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487\n device_add+0xc2f/0x2180 drivers/base/core.c:3354\n usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()\r\n\r\nset_memory_ro() can fail, leaving memory unprotected.\r\n\r\nCheck its return and take it into account as an error.(CVE-2024-42068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: can: j1939: Initialize unused data in j1939_send_one()\r\n\r\nsyzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()\ncreates full frame including unused data, but it doesn\u0026apos;t initialize\nit. This causes the kernel-infoleak issue. Fix this by initializing\nunused data.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: 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 memcpy_to_msg include/linux/skbuff.h:4113 [inline]\n raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n ____sys_recvmsg+0x18a/0x620 net/socket.c:2803\n ___sys_recvmsg+0x223/0x840 net/socket.c:2845\n do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034\n x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300\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+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1313 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n sock_alloc_send_skb include/net/sock.h:1842 [inline]\n j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]\n j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]\n j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277\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 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47\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+0x77/0x7f\r\n\r\nBytes 12-15 of 16 are uninitialized\nMemory access of size 16 starts at ffff888120969690\nData copied to user address 00000000200017c0\r\n\r\nCPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix DIO failure due to insufficient transaction credits\r\n\r\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits().  This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\r\n\r\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases.  For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents.  Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) \u0026lt;= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error.  This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\r\n\r\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\r\n\r\nHeming Zhao said:\r\n\r\n------\nPANIC: \u0026quot;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\u0026quot;\r\n\r\nPID: xxx  TASK: xxxx  CPU: 5  COMMAND: \u0026quot;SubmitThread-CA\u0026quot;\n  #0 machine_kexec at ffffffff8c069932\n  #1 __crash_kexec at ffffffff8c1338fa\n  #2 panic at ffffffff8c1d69b9\n  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/restrack: Fix potential invalid address access\r\n\r\nstruct rdma_restrack_entry\u0026apos;s kern_name was set to KBUILD_MODNAME\nin ib_create_cq(), while if the module exited but forgot del this\nrdma_restrack_entry, it would cause a invalid address access in\nrdma_restrack_clean() when print the owner of this rdma_restrack_entry.\r\n\r\nThese code is used to help find one forgotten PD release in one of the\nULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: Remove WARN() from __xdp_reg_mem_model()\r\n\r\nsyzkaller reports a warning in __xdp_reg_mem_model().\r\n\r\nThe warning occurs only if __mem_id_init_hash_table() returns an error. It\nreturns the error in two cases:\r\n\r\n  1. memory allocation fails;\n  2. rhashtable_init() fails when some fields of rhashtable_params\n     struct are not initialized properly.\r\n\r\nThe second case cannot happen since there is a static const rhashtable_params\nstruct with valid fields. So, warning is only triggered when there is a\nproblem with memory allocation.\r\n\r\nThus, there is no sense in using WARN() to handle this error and it can be\nsafely removed.\r\n\r\nWARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\r\n\r\nCPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\r\n\r\nCall Trace:\n xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344\n xdp_test_run_setup net/bpf/test_run.c:188 [inline]\n bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377\n bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267\n bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240\n __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649\n __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftruncate: pass a signed offset\r\n\r\nThe old ftruncate() syscall, using the 32-bit off_t misses a sign\nextension when called in compat mode on 64-bit architectures.  As a\nresult, passing a negative length accidentally succeeds in truncating\nto file size between 2GiB and 4GiB.\r\n\r\nChanging the type of the compat syscall to the signed compat_off_t\nchanges the behavior so it instead returns -EINVAL.\r\n\r\nThe native entry point, the truncate() syscall and the corresponding\nloff_t based variants are all correct already and do not suffer\nfrom this mistake.(CVE-2024-42084)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: chemical: bme680: Fix overflows in compensate() functions\r\n\r\nThere are cases in the compensate functions of the driver that\nthere could be overflows of variables due to bit shifting ops.\nThese implications were initially discussed here [1] and they\nwere mentioned in log message of Commit 1b3bd8592780 (\u0026quot;iio:\nchemical: Add support for Bosch BME680 sensor\u0026quot;).\r\n\r\n[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: fsl-asoc-card: set priv-\u0026gt;pdev before using it\r\n\r\npriv-\u0026gt;pdev pointer was set after being used in\nfsl_asoc_card_audmux_init().\nMove this assignment at the start of the probe function, so\nsub-functions can correctly use pdev through priv.\r\n\r\nfsl_asoc_card_audmux_init() dereferences priv-\u0026gt;pdev to get access to the\ndev struct, used with dev_err macros.\nAs priv is zero-initialised, there would be a NULL pointer dereference.\nNote that if priv-\u0026gt;dev is dereferenced before assignment but never used,\nfor example if there is no error to be printed, the driver won\u0026apos;t crash\nprobably due to compiler optimisations.(CVE-2024-42089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\r\n\r\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\r\n\r\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: davinci: Validate the obtained number of IRQs\r\n\r\nValue of pdata-\u0026gt;gpio_unbanked is taken from Device Tree. In case of broken\nDT due to any error this value can be any. Without this value validation\nthere can be out of chips-\u0026gt;irqs array boundaries access in\ndavinci_gpio_probe().\r\n\r\nValidate the obtained nirq value so that it won\u0026apos;t exceed the maximum\nnumber of IRQs per bank.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/dpaa2: Avoid explicit cpumask var allocation on stack\r\n\r\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\r\n\r\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\r\n\r\nUse *cpumask_var API(s) to address it.(CVE-2024-42093)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: Avoid explicit cpumask var allocation on stack\r\n\r\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\r\n\r\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\r\n\r\nUse *cpumask_var API(s) to address it.(CVE-2024-42094)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emux: improve patch ioctl data validation\r\n\r\nIn load_data(), make the validation of and skipping over the main info\nblock match that in load_guspatch().\r\n\r\nIn load_guspatch(), add checking that the specified patch length matches\nthe actually supplied data, like load_data() already did.(CVE-2024-42097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: fix null pointer dereference in nouveau_connector_get_modes\r\n\r\nIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet_diag: Initialize pad field in struct inet_diag_req_v2\r\n\r\nKMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw\nsockets uses the pad field in struct inet_diag_req_v2 for the\nunderlying protocol. This field corresponds to the sdiag_raw_protocol\nfield in struct inet_diag_req_raw.\r\n\r\ninet_diag_get_exact_compat() converts inet_diag_req to\ninet_diag_req_v2, but leaves the pad field uninitialized. So the issue\noccurs when raw_lookup() accesses the sdiag_raw_protocol field.\r\n\r\nFix this by initializing the pad field in\ninet_diag_get_exact_compat(). Also, do the same fix in\ninet_diag_dump_compat() to avoid the similar issue in the future.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]\nBUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_lookup net/ipv4/raw_diag.c:49 [inline]\n raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was stored to memory at:\n raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nLocal variable req.i created at:\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]\n inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\r\n\r\nCPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: Fix potential illegal address access in jffs2_free_inode\r\n\r\nDuring the stress testing of the jffs2 file system,the following\nabnormal printouts were found:\n[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948\n[ 2430.649622] Mem abort info:\n[ 2430.649829]   ESR = 0x96000004\n[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2430.650564]   SET = 0, FnV = 0\n[ 2430.650795]   EA = 0, S1PTW = 0\n[ 2430.651032]   FSC = 0x04: level 0 translation fault\n[ 2430.651446] Data abort info:\n[ 2430.651683]   ISV = 0, ISS = 0x00000004\n[ 2430.652001]   CM = 0, WnR = 0\n[ 2430.652558] [0069696969696948] address between user and kernel address ranges\n[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33\n[ 2430.655008] Hardware name: linux,dummy-virt (DT)\n[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2430.656142] pc : kfree+0x78/0x348\n[ 2430.656630] lr : jffs2_free_inode+0x24/0x48\n[ 2430.657051] sp : ffff800009eebd10\n[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000\n[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000\n[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14\n[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000\n[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000\n[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19\n[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14\n[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302\n[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342\n[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000\n[ 2430.664217] Call trace:\n[ 2430.664528]  kfree+0x78/0x348\n[ 2430.664855]  jffs2_free_inode+0x24/0x48\n[ 2430.665233]  i_callback+0x24/0x50\n[ 2430.665528]  rcu_do_batch+0x1ac/0x448\n[ 2430.665892]  rcu_core+0x28c/0x3c8\n[ 2430.666151]  rcu_core_si+0x18/0x28\n[ 2430.666473]  __do_softirq+0x138/0x3cc\n[ 2430.666781]  irq_exit+0xf0/0x110\n[ 2430.667065]  handle_domain_irq+0x6c/0x98\n[ 2430.667447]  gic_handle_irq+0xac/0xe8\n[ 2430.667739]  call_on_irq_stack+0x28/0x54\nThe parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of\nthe jffs_inode_info structure. It was found that all variables in the jffs_inode_info\nstructure were 5a5a5a5a, except for the first member sem. It is suspected that these\nvariables are not initialized because they were set to 5a5a5a5a during memory testing,\nwhich is meant to detect uninitialized memory.The sem variable is initialized in the\nfunction jffs2_i_init_once, while other members are initialized in\nthe function jffs2_init_inode_info.\r\n\r\nThe function jffs2_init_inode_info is called after iget_locked,\nbut in the iget_locked function, the destroy_inode process is triggered,\nwhich releases the inode and consequently, the target member of the inode\nis not initialized.In concurrent high pressure scenarios, iget_locked\nmay enter the destroy_inode branch as described in the code.\r\n\r\nSince the destroy_inode functionality of jffs2 only releases the target,\nthe fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedf: Make qedf_execute_tmf() non-preemptible\r\n\r\nStop calling smp_processor_id() from preemptible code in\nqedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.\r\n\r\n[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646\n[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf](CVE-2024-42124)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: mlxreg: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42129)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/core: Implement a limit on UMAD receive List\r\n\r\nThe existing behavior of ib_umad, which maintains received MAD\npackets in an unbounded list, poses a risk of uncontrolled growth.\nAs user-space applications extract packets from this list, the rate\nof extraction may not match the rate of incoming packets, leading\nto potential list overflow.\r\n\r\nTo address this, we introduce a limit to the size of the list. After\nconsidering typical scenarios, such as OpenSM processing, which can\nhandle approximately 100k packets per second, and the 1-second retry\ntimeout for most packets, we set the list size limit to 200k. Packets\nreceived beyond this limit are dropped, assuming they are likely timed\nout by the time they are handled by user-space.\r\n\r\nNotably, packets queued on the receive list due to reasons like\ntimed-out sends are preserved even when the list is full.(CVE-2024-42145)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of protected- and secure-keys\r\n\r\nAlthough the clear-key of neither protected- nor secure-keys is\naccessible, this key material should only be visible to the calling\nprocess. So wipe all copies of protected- or secure-keys from stack,\neven in case of an error.(CVE-2024-42155)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: check validation of fault attrs in f2fs_build_fault_attr()\r\n\r\n- It missed to check validation of fault attrs in parse_options(),\nlet\u0026apos;s fix to add check condition in f2fs_build_fault_attr().\n- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD\r\n\r\n[Changes from V1:\n - Use a default branch in the switch statement to initialize `val\u0026apos;.]\r\n\r\nGCC warns that `val\u0026apos; may be used uninitialized in the\nBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:\r\n\r\n\t[...]\n\tunsigned long long val;\t\t\t\t\t\t      \\\n\t[...]\t\t\t\t\t\t\t\t      \\\n\tswitch (__CORE_RELO(s, field, BYTE_SIZE)) {\t\t\t      \\\n\tcase 1: val = *(const unsigned char *)p; break;\t\t\t      \\\n\tcase 2: val = *(const unsigned short *)p; break;\t\t      \\\n\tcase 4: val = *(const unsigned int *)p; break;\t\t\t      \\\n\tcase 8: val = *(const unsigned long long *)p; break;\t\t      \\\n        }       \t\t\t\t\t\t\t      \\\n\t[...]\n\tval;\t\t\t\t\t\t\t\t      \\\n\t}\t\t\t\t\t\t\t\t      \\\r\n\r\nThis patch adds a default entry in the switch statement that sets\n`val\u0026apos; to zero in order to avoid the warning, and random values to be\nused in case __builtin_preserve_field_info returns unexpected values\nfor BPF_FIELD_BYTE_SIZE.\r\n\r\nTested in bpf-next master.\nNo regressions.(CVE-2024-42161)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngve: Account for stopped queues when reading NIC stats\r\n\r\nWe now account for the fact that the NIC might send us stats for a\nsubset of queues. Without this change, gve_get_ethtool_stats might make\nan invalid access on the priv-\u0026gt;stats_report-\u0026gt;stats array.(CVE-2024-42162)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: mv88e6xxx: Correct check for empty list\r\n\r\nSince commit a3c53be55c95 (\u0026quot;net: dsa: mv88e6xxx: Support multiple MDIO\nbusses\u0026quot;) mv88e6xxx_default_mdio_bus() has checked that the\nreturn value of list_first_entry() is non-NULL.\r\n\r\nThis appears to be intended to guard against the list chip-\u0026gt;mdios being\nempty.  However, it is not the correct check as the implementation of\nlist_first_entry is not designed to return NULL for empty lists.\r\n\r\nInstead, use list_first_entry_or_null() which does return NULL if the\nlist is empty.\r\n\r\nFlagged by Smatch.\nCompile tested only.(CVE-2024-42224)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc\r\n\r\nInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.\nV2: To really improve the handling we would actually\n   need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)",
  "id": "OESA-2024-1964",
  "modified": "2026-08-06T11:07:26Z",
  "published": "2024-08-09T11:07:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47382"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52764"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52887"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35904"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38546"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38561"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38594"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38627"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39471"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39497"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40953"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40959"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40976"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41013"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41020"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41023"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41027"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41040"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41041"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41048"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41062"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41064"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41069"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41070"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41072"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41077"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41079"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41080"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41081"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41090"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42068"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42077"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42080"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42084"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42086"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42090"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42092"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42094"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42101"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42106"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42115"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42124"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42129"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42145"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42155"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42161"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42162"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42224"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42228"
    }
  ],
  "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-47382",
    "CVE-2023-52674",
    "CVE-2023-52764",
    "CVE-2023-52887",
    "CVE-2024-33621",
    "CVE-2024-35904",
    "CVE-2024-38546",
    "CVE-2024-38561",
    "CVE-2024-38594",
    "CVE-2024-38627",
    "CVE-2024-39471",
    "CVE-2024-39497",
    "CVE-2024-40910",
    "CVE-2024-40953",
    "CVE-2024-40959",
    "CVE-2024-40961",
    "CVE-2024-40976",
    "CVE-2024-40982",
    "CVE-2024-40988",
    "CVE-2024-40999",
    "CVE-2024-41013",
    "CVE-2024-41014",
    "CVE-2024-41019",
    "CVE-2024-41020",
    "CVE-2024-41022",
    "CVE-2024-41023",
    "CVE-2024-41027",
    "CVE-2024-41040",
    "CVE-2024-41041",
    "CVE-2024-41044",
    "CVE-2024-41048",
    "CVE-2024-41062",
    "CVE-2024-41063",
    "CVE-2024-41064",
    "CVE-2024-41069",
    "CVE-2024-41070",
    "CVE-2024-41072",
    "CVE-2024-41077",
    "CVE-2024-41079",
    "CVE-2024-41080",
    "CVE-2024-41081",
    "CVE-2024-41089",
    "CVE-2024-41090",
    "CVE-2024-41091",
    "CVE-2024-41097",
    "CVE-2024-42068",
    "CVE-2024-42076",
    "CVE-2024-42077",
    "CVE-2024-42080",
    "CVE-2024-42082",
    "CVE-2024-42084",
    "CVE-2024-42086",
    "CVE-2024-42089",
    "CVE-2024-42090",
    "CVE-2024-42092",
    "CVE-2024-42093",
    "CVE-2024-42094",
    "CVE-2024-42097",
    "CVE-2024-42101",
    "CVE-2024-42106",
    "CVE-2024-42115",
    "CVE-2024-42124",
    "CVE-2024-42129",
    "CVE-2024-42145",
    "CVE-2024-42155",
    "CVE-2024-42160",
    "CVE-2024-42161",
    "CVE-2024-42162",
    "CVE-2024-42224",
    "CVE-2024-42228"
  ]
}