{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "perf-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-46.0.0.51.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-46.0.0.51.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-46.0.0.51.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "perf-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-46.0.0.51.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-46.0.0.51.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-46.0.0.51.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: fix a possible DMA corruption\r\n\r\nARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be\npossible that two unrelated 16-byte allocations share a cache line. If\none of these allocations is written using DMA and the other is written\nusing cached write, the value that was written with DMA may be\ncorrupted.\r\n\r\nThis commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -\nthat\u0026apos;s the largest possible cache line size.\r\n\r\nAs different parisc microarchitectures have different cache line size, we\ndefine arch_slab_minalign(), cache_line_size() and\ndma_get_cache_alignment() so that the kernel may tune slab cache\nparameters dynamically, based on the detected cache line size.(CVE-2024-44949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only decrement add_addr_accepted for MPJ req\r\n\r\nAdding the following warning ...\r\n\r\n  WARN_ON_ONCE(msk-\u0026gt;pm.add_addr_accepted == 0)\r\n\r\n... before decrementing the add_addr_accepted counter helped to find a\nbug when running the \u0026quot;remove single subflow\u0026quot; subtest from the\nmptcp_join.sh selftest.\r\n\r\nRemoving a \u0026apos;subflow\u0026apos; endpoint will first trigger a RM_ADDR, then the\nsubflow closure. Before this patch, and upon the reception of the\nRM_ADDR, the other peer will then try to decrement this\nadd_addr_accepted. That\u0026apos;s not correct because the attached subflows have\nnot been created upon the reception of an ADD_ADDR.\r\n\r\nA way to solve that is to decrement the counter only if the attached\nsubflow was an MP_JOIN to a remote id that was not 0, and initiated by\nthe host receiving the RM_ADDR.(CVE-2024-45009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nchar: xillybus: Check USB endpoints when probing device\r\n\r\nEnsure, as the driver probes the device, that all endpoints that the\ndriver may attempt to access exist and are of the correct type.\r\n\r\nAll XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at\naddress 1. This is verified in xillyusb_setup_base_eps().\r\n\r\nOn top of that, a XillyUSB device may have additional Bulk OUT\nendpoints. The information about these endpoints\u0026apos; addresses is deduced\nfrom a data structure (the IDT) that the driver fetches from the device\nwhile probing it. These endpoints are checked in setup_channels().\r\n\r\nA XillyUSB device never has more than one IN endpoint, as all data\ntowards the host is multiplexed in this single Bulk IN endpoint. This is\nwhy setup_channels() only checks OUT endpoints.(CVE-2024-45011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: tegra: Do not mark ACPI devices as irq safe\r\n\r\nOn ACPI machines, the tegra i2c module encounters an issue due to a\nmutex being called inside a spinlock. This leads to the following bug:\r\n\r\n\tBUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\n\t...\r\n\r\n\tCall trace:\n\t__might_sleep\n\t__mutex_lock_common\n\tmutex_lock_nested\n\tacpi_subsys_runtime_resume\n\trpm_resume\n\ttegra_i2c_xfer\r\n\r\nThe problem arises because during __pm_runtime_resume(), the spinlock\n\u0026amp;dev-\u0026gt;power.lock is acquired before rpm_resume() is called. Later,\nrpm_resume() invokes acpi_subsys_runtime_resume(), which relies on\nmutexes, triggering the error.\r\n\r\nTo address this issue, devices on ACPI are now marked as not IRQ-safe,\nconsidering the dependency of acpi_subsys_runtime_resume() on mutexes.(CVE-2024-45029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()\r\n\r\nThis happens when called from SMB2_read() while using rdma\nand reaching the rdma_readwrite_threshold.(CVE-2024-46686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibfs: fix infinite directory reads for offset dir\r\n\r\nAfter we switch tmpfs dir operations from simple_dir_operations to\nsimple_offset_dir_operations, every rename happened will fill new dentry\nto dest dir\u0026apos;s maple tree(\u0026amp;SHMEM_I(inode)-\u0026gt;dir_offsets-\u0026gt;mt) with a free\nkey starting with octx-\u0026gt;newx_offset, and then set newx_offset equals to\nfree key + 1. This will lead to infinite readdir combine with rename\nhappened at the same time, which fail generic/736 in xfstests(detail show\nas below).\r\n\r\n1. create 5000 files(1 2 3...) under one dir\n2. call readdir(man 3 readdir) once, and get one entry\n3. rename(entry, \u0026quot;TEMPFILE\u0026quot;), then rename(\u0026quot;TEMPFILE\u0026quot;, entry)\n4. loop 2~3, until readdir return nothing or we loop too many\n   times(tmpfs break test with the second condition)\r\n\r\nWe choose the same logic what commit 9b378f6ad48cf (\u0026quot;btrfs: fix infinite\ndirectory reads\u0026quot;) to fix it, record the last_index when we open dir, and\ndo not emit the entry which index \u0026gt;= last_index. The file-\u0026gt;private_data\nnow used in offset dir can use directly to do this, and we also update\nthe last_index when we llseek the dir file.\r\n\r\n[brauner: only update last_index after seek when offset is zero like Jan suggested](CVE-2024-46701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: SHAMPO, Fix incorrect page release\r\n\r\nUnder the following conditions:\n1) No skb created yet\n2) header_size == 0 (no SHAMPO header)\n3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the\n   last page fragment of a SHAMPO header page)\r\n\r\na new skb is formed with a page that is NOT a SHAMPO header page (it\nis a regular data page). Further down in the same function\n(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from\nheader_index is released. This is wrong and it leads to SHAMPO header\npages being released more than once.(CVE-2024-46717)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check index for aux_rd_interval before using\r\n\r\naux_rd_interval has size of 7 and should be checked.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46728)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix race between direct IO write and fsync when using same fd\r\n\r\nIf we have 2 threads that are using the same file descriptor and one of\nthem is doing direct IO writes while the other is doing fsync, we have a\nrace where we can end up either:\r\n\r\n1) Attempt a fsync without holding the inode\u0026apos;s lock, triggering an\n   assertion failures when assertions are enabled;\r\n\r\n2) Do an invalid memory access from the fsync task because the file private\n   points to memory allocated on stack by the direct IO task and it may be\n   used by the fsync task after the stack was destroyed.\r\n\r\nThe race happens like this:\r\n\r\n1) A user space program opens a file descriptor with O_DIRECT;\r\n\r\n2) The program spawns 2 threads using libpthread for example;\r\n\r\n3) One of the threads uses the file descriptor to do direct IO writes,\n   while the other calls fsync using the same file descriptor.\r\n\r\n4) Call task A the thread doing direct IO writes and task B the thread\n   doing fsyncs;\r\n\r\n5) Task A does a direct IO write, and at btrfs_direct_write() sets the\n   file\u0026apos;s private to an on stack allocated private with the member\n   \u0026apos;fsync_skip_inode_lock\u0026apos; set to true;\r\n\r\n6) Task B enters btrfs_sync_file() and sees that there\u0026apos;s a private\n   structure associated to the file which has \u0026apos;fsync_skip_inode_lock\u0026apos; set\n   to true, so it skips locking the inode\u0026apos;s VFS lock;\r\n\r\n7) Task A completes the direct IO write, and resets the file\u0026apos;s private to\n   NULL since it had no prior private and our private was stack allocated.\n   Then it unlocks the inode\u0026apos;s VFS lock;\r\n\r\n8) Task B enters btrfs_get_ordered_extents_for_logging(), then the\n   assertion that checks the inode\u0026apos;s VFS lock is held fails, since task B\n   never locked it and task A has already unlocked it.\r\n\r\nThe stack trace produced is the following:\r\n\r\n   assertion failed: inode_is_locked(\u0026amp;inode-\u0026gt;vfs_inode), in fs/btrfs/ordered-data.c:983\n   ------------[ cut here ]------------\n   kernel BUG at fs/btrfs/ordered-data.c:983!\n   Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n   CPU: 9 PID: 5072 Comm: worker Tainted: G     U     OE      6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8\n   Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020\n   RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]\n   Code: 50 d6 86 c0 e8 (...)\n   RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246\n   RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000\n   RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800\n   RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38\n   R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800\n   R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000\n   FS:  00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000\n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n   CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    ? __die_body.cold+0x14/0x24\n    ? die+0x2e/0x50\n    ? do_trap+0xca/0x110\n    ? do_error_trap+0x6a/0x90\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? exc_invalid_op+0x50/0x70\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? asm_exc_invalid_op+0x1a/0x20\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? __seccomp_filter+0x31d/0x4f0\n    __x64_sys_fdatasync+0x4f/0x90\n    do_syscall_64+0x82/0x160\n    ? do_futex+0xcb/0x190\n    ? __x64_sys_futex+0x10e/0x1d0\n    ? switch_fpu_return+0x4f/0xd0\n    ? syscall_exit_to_user_mode+0x72/0x220\n    ? do_syscall_64+0x8e/0x160\n    ? syscall_exit_to_user_mod\n---truncated---(CVE-2024-46734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix double put of @cfile in smb2_rename_path()\r\n\r\nIf smb2_set_path_attr() is called with a valid @cfile and returned\n-EINVAL, we need to call cifs_get_writable_path() again as the\nreference of @cfile was already dropped by previous smb2_compound_op()\ncall.(CVE-2024-46736)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtw88: usb: schedule rx work after everything is set up\r\n\r\nRight now it\u0026apos;s possible to hit NULL pointer dereference in\nrtw_rx_fill_rx_status on hw object and/or its fields because\ninitialization routine can start getting USB replies before\nrtw_dev is fully setup.\r\n\r\nThe stack trace looks like this:\r\n\r\nrtw_rx_fill_rx_status\nrtw8821c_query_rx_desc\nrtw_usb_rx_handler\n...\nqueue_work\nrtw_usb_read_port_complete\n...\nusb_submit_urb\nrtw_usb_rx_resubmit\nrtw_usb_init_rx\nrtw_usb_probe\r\n\r\nSo while we do the async stuff rtw_usb_probe continues and calls\nrtw_register_hw, which does all kinds of initialization (e.g.\nvia ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.\r\n\r\nFix this by moving the first usb_submit_urb after everything\nis set up.\r\n\r\nFor me, this bug manifested as:\n[    8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped\n[    8.910904] rtw_8821cu 1-1:1.2: hw-\u0026gt;conf.chandef.chan NULL in rtw_rx_fill_rx_status\nbecause I\u0026apos;m using Larry\u0026apos;s backport of rtw88 driver with the NULL\nchecks in rtw_rx_fill_rx_status.(CVE-2024-46760)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: phy: Fix missing of_node_put() for leds\r\n\r\nThe call of of_get_child_by_name() will cause refcount incremented\nfor leds, if it succeeds, it should call of_node_put() to decrease\nit, fix it.(CVE-2024-46767)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (hp-wmi-sensors) Check if WMI event data exists\r\n\r\nThe BIOS can choose to return no event data in response to a\nWMI event, so the ACPI object passed to the WMI notify handler\ncan be NULL.\r\n\r\nCheck for such a situation and ignore the event in such a case.(CVE-2024-46768)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check denominator crb_pipes before used\r\n\r\n[WHAT \u0026amp; HOW]\nA denominator cannot be 0, and is checked before used.\r\n\r\nThis fixes 2 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-46772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check denominator pbn_div before used\r\n\r\n[WHAT \u0026amp; HOW]\nA denominator cannot be 0, and is checked before used.\r\n\r\nThis fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.(CVE-2024-46773)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Run DC_LOG_DC after checking link-\u0026gt;link_enc\r\n\r\n[WHAT]\nThe DC_LOG_DC should be run after link-\u0026gt;link_enc is checked, not before.\r\n\r\nThis fixes 1 REVERSE_INULL issue reported by Coverity.(CVE-2024-46776)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mana: Fix error handling in mana_create_txq/rxq\u0026apos;s NAPI cleanup\r\n\r\nCurrently napi_disable() gets called during rxq and txq cleanup,\neven before napi is enabled and hrtimer is initialized. It causes\nkernel panic.\r\n\r\n? page_fault_oops+0x136/0x2b0\n  ? page_counter_cancel+0x2e/0x80\n  ? do_user_addr_fault+0x2f2/0x640\n  ? refill_obj_stock+0xc4/0x110\n  ? exc_page_fault+0x71/0x160\n  ? asm_exc_page_fault+0x27/0x30\n  ? __mmdrop+0x10/0x180\n  ? __mmdrop+0xec/0x180\n  ? hrtimer_active+0xd/0x50\n  hrtimer_try_to_cancel+0x2c/0xf0\n  hrtimer_cancel+0x15/0x30\n  napi_disable+0x65/0x90\n  mana_destroy_rxq+0x4c/0x2f0\n  mana_create_rxq.isra.0+0x56c/0x6d0\n  ? mana_uncfg_vport+0x50/0x50\n  mana_alloc_queues+0x21b/0x320\n  ? skb_dequeue+0x5f/0x80(CVE-2024-46784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n   the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n   some extra mdelay() calls. See the commit message for a description\n   of the race scenario.\n   On older kernels (before 6.5), I think the same bug can even\n   theoretically lead to accessing transhuge page contents as a page table\n   if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n   detecting PMDs that don\u0026apos;t point to page tables.\n   On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n   wide race to hit this.\n   I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n   VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n   to yank page tables out from under us (though I haven\u0026apos;t tested that),\n   so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n  mfill_atomic                other thread\n  ============                ============\n                              \u0026lt;zap PMD\u0026gt;\n  pmdp_get_lockless() [reads none pmd]\n  \u0026lt;bail if trans_huge\u0026gt;\n  \u0026lt;if none:\u0026gt;\n                              \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n    __pte_alloc [no-op]\n                              \u0026lt;zap PMD\u0026gt;\n  \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n  BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/osnoise: Use a cpumask to know what threads are kthreads\r\n\r\nThe start_kthread() and stop_thread() code was not always called with the\ninterface_lock held. This means that the kthread variable could be\nunexpectedly changed causing the kthread_stop() to be called on it when it\nshould not have been, leading to:\r\n\r\n while true; do\n   rtla timerlat top -u -q \u0026amp; PID=$!;\n   sleep 5;\n   kill -INT $PID;\n   sleep 0.001;\n   kill -TERM $PID;\n   wait $PID;\n  done\r\n\r\nCausing the following OOPS:\r\n\r\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:hrtimer_active+0x58/0x300\n Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 \u0026lt;0f\u0026gt; b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f\n RSP: 0018:ffff88811d97f940 EFLAGS: 00010202\n RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b\n RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28\n RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60\n R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d\n R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28\n FS:  0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? die_addr+0x40/0xa0\n  ? exc_general_protection+0x154/0x230\n  ? asm_exc_general_protection+0x26/0x30\n  ? hrtimer_active+0x58/0x300\n  ? __pfx_mutex_lock+0x10/0x10\n  ? __pfx_locks_remove_file+0x10/0x10\n  hrtimer_cancel+0x15/0x40\n  timerlat_fd_release+0x8e/0x1f0\n  ? security_file_release+0x43/0x80\n  __fput+0x372/0xb10\n  task_work_run+0x11e/0x1f0\n  ? _raw_spin_lock+0x85/0xe0\n  ? __pfx_task_work_run+0x10/0x10\n  ? poison_slab_object+0x109/0x170\n  ? do_exit+0x7a0/0x24b0\n  do_exit+0x7bd/0x24b0\n  ? __pfx_migrate_enable+0x10/0x10\n  ? __pfx_do_exit+0x10/0x10\n  ? __pfx_read_tsc+0x10/0x10\n  ? ktime_get+0x64/0x140\n  ? _raw_spin_lock_irq+0x86/0xe0\n  do_group_exit+0xb0/0x220\n  get_signal+0x17ba/0x1b50\n  ? vfs_read+0x179/0xa40\n  ? timerlat_fd_read+0x30b/0x9d0\n  ? __pfx_get_signal+0x10/0x10\n  ? __pfx_timerlat_fd_read+0x10/0x10\n  arch_do_signal_or_restart+0x8c/0x570\n  ? __pfx_arch_do_signal_or_restart+0x10/0x10\n  ? vfs_read+0x179/0xa40\n  ? ksys_read+0xfe/0x1d0\n  ? __pfx_ksys_read+0x10/0x10\n  syscall_exit_to_user_mode+0xbc/0x130\n  do_syscall_64+0x74/0x110\n  ? __pfx___rseq_handle_notify_resume+0x10/0x10\n  ? __pfx_ksys_read+0x10/0x10\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? syscall_exit_to_user_mode+0x116/0x130\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  entry_SYSCALL_64_after_hwframe+0x71/0x79\n RIP: 0033:0x7ff0070eca9c\n Code: Unable to access opcode bytes at 0x7ff0070eca72.\n RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c\n RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003\n RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0\n R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003\n R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008\n  \u0026lt;/TASK\u0026gt;\n Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core\n ---[ end trace 0000000000000000 ]---\r\n\r\nThis is because it would mistakenly call kthread_stop() on a user space\nthread making it \u0026quot;exit\u0026quot; before it actually exits.\r\n\r\nSince kthread\n---truncated---(CVE-2024-46788)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix double put of @cfile in smb2_set_path_size()\r\n\r\nIf smb2_compound_op() is called with a valid @cfile and returned\n-EINVAL, we need to call cifs_get_writable_path() before retrying it\nas the reference of @cfile was already dropped by previous call.\r\n\r\nThis fixes the following KASAN splat when running fstests generic/013\nagainst Windows Server 2022:\r\n\r\n  CIFS: Attempting to mount //w22-fs0/scratch\n  run fstests generic/013 at 2024-09-02 19:48:59\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200\n  Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176\r\n\r\n  CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40\n  04/01/2014\n  Workqueue: cifsoplockd cifs_oplock_break [cifs]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x5d/0x80\n   ? detach_if_pending+0xab/0x200\n   print_report+0x156/0x4d9\n   ? detach_if_pending+0xab/0x200\n   ? __virt_addr_valid+0x145/0x300\n   ? __phys_addr+0x46/0x90\n   ? detach_if_pending+0xab/0x200\n   kasan_report+0xda/0x110\n   ? detach_if_pending+0xab/0x200\n   detach_if_pending+0xab/0x200\n   timer_delete+0x96/0xe0\n   ? __pfx_timer_delete+0x10/0x10\n   ? rcu_is_watching+0x20/0x50\n   try_to_grab_pending+0x46/0x3b0\n   __cancel_work+0x89/0x1b0\n   ? __pfx___cancel_work+0x10/0x10\n   ? kasan_save_track+0x14/0x30\n   cifs_close_deferred_file+0x110/0x2c0 [cifs]\n   ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs]\n   ? __pfx_down_read+0x10/0x10\n   cifs_oplock_break+0x4c1/0xa50 [cifs]\n   ? __pfx_cifs_oplock_break+0x10/0x10 [cifs]\n   ? lock_is_held_type+0x85/0xf0\n   ? mark_held_locks+0x1a/0x90\n   process_one_work+0x4c6/0x9f0\n   ? find_held_lock+0x8a/0xa0\n   ? __pfx_process_one_work+0x10/0x10\n   ? lock_acquired+0x220/0x550\n   ? __list_add_valid_or_report+0x37/0x100\n   worker_thread+0x2e4/0x570\n   ? __kthread_parkme+0xd1/0xf0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x17f/0x1c0\n   ? kthread+0xda/0x1c0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x31/0x60\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u0026lt;/TASK\u0026gt;\r\n\r\n  Allocated by task 1118:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0xaa/0xb0\n   cifs_new_fileinfo+0xc8/0x9d0 [cifs]\n   cifs_atomic_open+0x467/0x770 [cifs]\n   lookup_open.isra.0+0x665/0x8b0\n   path_openat+0x4c3/0x1380\n   do_filp_open+0x167/0x270\n   do_sys_openat2+0x129/0x160\n   __x64_sys_creat+0xad/0xe0\n   do_syscall_64+0xbb/0x1d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n  Freed by task 83:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   kasan_save_free_info+0x3b/0x70\n   poison_slab_object+0xe9/0x160\n   __kasan_slab_free+0x32/0x50\n   kfree+0xf2/0x300\n   process_one_work+0x4c6/0x9f0\n   worker_thread+0x2e4/0x570\n   kthread+0x17f/0x1c0\n   ret_from_fork+0x31/0x60\n   ret_from_fork_asm+0x1a/0x30\r\n\r\n  Last potentially related work creation:\n   kasan_save_stack+0x30/0x50\n   __kasan_record_aux_stack+0xad/0xc0\n   insert_work+0x29/0xe0\n   __queue_work+0x5ea/0x760\n   queue_work_on+0x6d/0x90\n   _cifsFileInfo_put+0x3f6/0x770 [cifs]\n   smb2_compound_op+0x911/0x3940 [cifs]\n   smb2_set_path_size+0x228/0x270 [cifs]\n   cifs_set_file_size+0x197/0x460 [cifs]\n   cifs_setattr+0xd9c/0x14b0 [cifs]\n   notify_change+0x4e3/0x740\n   do_truncate+0xfa/0x180\n   vfs_truncate+0x195/0x200\n   __x64_sys_truncate+0x109/0x150\n   do_syscall_64+0xbb/0x1d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-46796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/qspinlock: Fix deadlock in MCS queue\r\n\r\nIf an interrupt occurs in queued_spin_lock_slowpath() after we increment\nqnodesp-\u0026gt;count and before node-\u0026gt;lock is initialized, another CPU might\nsee stale lock values in get_tail_qnode(). If the stale lock value happens\nto match the lock on that CPU, then we write to the \u0026quot;next\u0026quot; pointer of\nthe wrong qnode. This causes a deadlock as the former CPU, once it becomes\nthe head of the MCS queue, will spin indefinitely until it\u0026apos;s \u0026quot;next\u0026quot; pointer\nis set by its successor in the queue.\r\n\r\nRunning stress-ng on a 16 core (16EC/16VP) shared LPAR, results in\noccasional lockups similar to the following:\r\n\r\n   $ stress-ng --all 128 --vm-bytes 80% --aggressive \\\n               --maximize --oomable --verify  --syslog \\\n               --metrics  --times  --timeout 5m\r\n\r\n   watchdog: CPU 15 Hard LOCKUP\n   ......\n   NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   Call Trace:\n    0xc000002cfffa3bf0 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    raw_spin_rq_lock_nested.part.135+0x4c/0xd0\n    sched_ttwu_pending+0x60/0x1f0\n    __flush_smp_call_function_queue+0x1dc/0x670\n    smp_ipi_demux_relaxed+0xa4/0x100\n    xive_muxed_ipi_action+0x20/0x40\n    __handle_irq_event_percpu+0x80/0x240\n    handle_irq_event_percpu+0x2c/0x80\n    handle_percpu_irq+0x84/0xd0\n    generic_handle_irq+0x54/0x80\n    __do_irq+0xac/0x210\n    __do_IRQ+0x74/0xd0\n    0x0\n    do_IRQ+0x8c/0x170\n    hardware_interrupt_common_virt+0x29c/0x2a0\n   --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490\n   ......\n   NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   --- interrupt: 500\n    0xc0000029c1a41d00 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    futex_wake+0x100/0x260\n    do_futex+0x21c/0x2a0\n    sys_futex+0x98/0x270\n    system_call_exception+0x14c/0x2f0\n    system_call_vectored_common+0x15c/0x2ec\r\n\r\nThe following code flow illustrates how the deadlock occurs.\nFor the sake of brevity, assume that both locks (A and B) are\ncontended and we call the queued_spin_lock_slowpath() function.\r\n\r\n        CPU0                                   CPU1\n        ----                                   ----\n  spin_lock_irqsave(A)                          |\n  spin_unlock_irqrestore(A)                     |\n    spin_lock(B)                                |\n         |                                      |\n         \u25bc                                      |\n   id = qnodesp-\u0026gt;count++;                       |\n  (Note that nodes[0].lock == A)                |\n         |                                      |\n         \u25bc                                      |\n      Interrupt                                 |\n  (happens before \u0026quot;nodes[0].lock = B\u0026quot;)          |\n         |                                      |\n         \u25bc                                      |\n  spin_lock_irqsave(A)                          |\n         |                                      |\n         \u25bc                                      |\n   id = qnodesp-\u0026gt;count++                        |\n   nodes[1].lock = A                            |\n         |                                      |\n         \u25bc                                      |\n  Tail of MCS queue                             |\n         |                             spin_lock_irqsave(A)\n         \u25bc                                      |\n  Head of MCS queue                             \u25bc\n         |                             CPU0 is previous tail\n         \u25bc                                      |\n   Spin indefinitely                            \u25bc\n  (until \u0026quot;nodes[1].next != NULL\u0026quot;)      prev = get_tail_qnode(A, CPU0)\n                                                |\n                                                \u25bc\n                                       prev == \u0026amp;qnodes[CPU0].nodes[0]\n                                     (as qnodes\n---truncated---(CVE-2024-46797)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the warning division or modulo by zero\r\n\r\nChecks the partition mode and returns an error for an invalid mode.(CVE-2024-46806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box\r\n\r\n[Why]\nCoverity reports OVERRUN warning. soc.num_states could\nbe 40. But array range of bw_params-\u0026gt;clk_table.entries is 8.\r\n\r\n[How]\nAssert if soc.num_states greater than 8.(CVE-2024-46811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration\r\n\r\n[Why]\nCoverity reports Memory - illegal accesses.\r\n\r\n[How]\nSkip inactive planes.(CVE-2024-46812)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath12k: fix firmware crash due to invalid peer nss\r\n\r\nCurrently, if the access point receives an association\nrequest containing an Extended HE Capabilities Information\nElement with an invalid MCS-NSS, it triggers a firmware\ncrash.\r\n\r\nThis issue arises when EHT-PHY capabilities shows support\nfor a bandwidth and MCS-NSS set for that particular\nbandwidth is filled by zeros and due to this, driver obtains\npeer_nss as 0 and sending this value to firmware causes\ncrash.\r\n\r\nAddress this issue by implementing a validation step for\nthe peer_nss value before passing it to the firmware. If\nthe value is greater than zero, proceed with forwarding\nit to the firmware. However, if the value is invalid,\nreject the association request to prevent potential\nfirmware crashes.\r\n\r\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1(CVE-2024-46827)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info\r\n\r\nThe MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the\nroutine unconditionally frees submitted mailbox commands regardless of\nreturn status.  The issue is that for MBX_TIMEOUT cases, when firmware\nreturns SFP information at a later time, that same mailbox memory region\nreferences previously freed memory in its cmpl routine.\r\n\r\nFix by adding checks for the MBX_TIMEOUT return code.  During mailbox\nresource cleanup, check the mbox flag to make sure that the wait did not\ntimeout.  If the MBOX_WAKE flag is not set, then do not free the resources\nbecause it will be freed when firmware completes the mailbox at a later\ntime in its cmpl routine.\r\n\r\nAlso, increase the timeout from 30 to 60 seconds to accommodate boot\nscripts requiring longer timeouts.(CVE-2024-46842)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: ufs: core: Remove SCSI host only if added\r\n\r\nIf host tries to remove ufshcd driver from a UFS device it would cause a\nkernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before\nadding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host\nhas been defered after MCQ configuration introduced by commit 0cab4023ec7b\n(\u0026quot;scsi: ufs: core: Defer adding host to SCSI if MCQ is supported\u0026quot;).\r\n\r\nTo guarantee that SCSI host is removed only if it has been added, set the\nscsi_host_added flag to true after adding a SCSI host and check whether it\nis set or not before removing it.(CVE-2024-46843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/timerlat: Only clear timer if a kthread exists\r\n\r\nThe timerlat tracer can use user space threads to check for osnoise and\ntimer latency. If the program using this is killed via a SIGTERM, the\nthreads are shutdown one at a time and another tracing instance can start\nup resetting the threads before they are fully closed. That causes the\nhrtimer assigned to the kthread to be shutdown and freed twice when the\ndying thread finally closes the file descriptors, causing a use-after-free\nbug.\r\n\r\nOnly cancel the hrtimer if the associated thread is still around. Also add\nthe interface_lock around the resetting of the tlat_var-\u0026gt;kthread.\r\n\r\nNote, this is just a quick fix that can be backported to stable. A real\nfix is to have a better synchronization between the shutdown of old\nthreads and the starting of new ones.(CVE-2024-46845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: rockchip: Resolve unbalanced runtime PM / system PM handling\r\n\r\nCommit e882575efc77 (\u0026quot;spi: rockchip: Suspend and resume the bus during\nNOIRQ_SYSTEM_SLEEP_PM ops\u0026quot;) stopped respecting runtime PM status and\nsimply disabled clocks unconditionally when suspending the system. This\ncauses problems when the device is already runtime suspended when we go\nto sleep -- in which case we double-disable clocks and produce a\nWARNing.\r\n\r\nSwitch back to pm_runtime_force_{suspend,resume}(), because that still\nseems like the right thing to do, and the aforementioned commit makes no\nexplanation why it stopped using it.\r\n\r\nAlso, refactor some of the resume() error handling, because it\u0026apos;s not\nactually a good idea to re-disable clocks on failure.(CVE-2024-46846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf: heaps: Fix off-by-one in CMA heap fault handler\r\n\r\nUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 (\u0026quot;dma-buf: heaps:\nDon\u0026apos;t track CMA dma-buf pages under RssFile\u0026quot;) it was possible to obtain\na mapping larger than the buffer size via mremap and bypass the overflow\ncheck in dma_buf_mmap_internal. When using such a mapping to attempt to\nfault past the end of the buffer, the CMA heap fault handler also checks\nthe fault offset against the buffer size, but gets the boundary wrong by\n1. Fix the boundary check so that we don\u0026apos;t read off the end of the pages\narray and insert an arbitrary page in the mapping.(CVE-2024-46852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)",
  "id": "OESA-2024-2219",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2219"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42067"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45009"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45029"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46686"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46717"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46734"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46736"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46760"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46767"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46768"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46776"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46784"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46787"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46788"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46797"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46806"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46812"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46827"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46842"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46843"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46845"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46852"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46857"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-42067",
    "CVE-2024-42312",
    "CVE-2024-44949",
    "CVE-2024-44958",
    "CVE-2024-45009",
    "CVE-2024-45011",
    "CVE-2024-45016",
    "CVE-2024-45028",
    "CVE-2024-45029",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46679",
    "CVE-2024-46681",
    "CVE-2024-46686",
    "CVE-2024-46695",
    "CVE-2024-46701",
    "CVE-2024-46717",
    "CVE-2024-46721",
    "CVE-2024-46722",
    "CVE-2024-46725",
    "CVE-2024-46728",
    "CVE-2024-46732",
    "CVE-2024-46734",
    "CVE-2024-46736",
    "CVE-2024-46737",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46750",
    "CVE-2024-46753",
    "CVE-2024-46755",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46760",
    "CVE-2024-46761",
    "CVE-2024-46767",
    "CVE-2024-46768",
    "CVE-2024-46771",
    "CVE-2024-46772",
    "CVE-2024-46773",
    "CVE-2024-46776",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781",
    "CVE-2024-46784",
    "CVE-2024-46787",
    "CVE-2024-46788",
    "CVE-2024-46791",
    "CVE-2024-46796",
    "CVE-2024-46797",
    "CVE-2024-46798",
    "CVE-2024-46804",
    "CVE-2024-46806",
    "CVE-2024-46811",
    "CVE-2024-46812",
    "CVE-2024-46814",
    "CVE-2024-46816",
    "CVE-2024-46818",
    "CVE-2024-46827",
    "CVE-2024-46829",
    "CVE-2024-46841",
    "CVE-2024-46842",
    "CVE-2024-46843",
    "CVE-2024-46844",
    "CVE-2024-46845",
    "CVE-2024-46846",
    "CVE-2024-46849",
    "CVE-2024-46852",
    "CVE-2024-46857"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-231.0.0.130.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-231.0.0.130.oe2203sp4"
            }
          ],
          "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\nbcache: fix variable length array abuse in btree_iter\r\n\r\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\r\n\r\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\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_ld_modes\r\n\r\nIn nv17_tv_get_ld_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(). Add a check to avoid npd.(CVE-2024-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\r\n\r\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\r\n\r\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\r\n\r\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Ensure index calculation will not overflow\r\n\r\n[WHY \u0026amp; HOW]\nMake sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will\nnever overflow and exceess array size.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -\u0026gt; addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix negative array index read\r\n\r\nAvoid using the negative values\nfor clk_idex as an index into an array pptable-\u0026gt;DpmDescriptor.\r\n\r\nV2: fix clk_index return check (Tim Huang)(CVE-2024-46821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: void array out of bound when loop tnl_num\r\n\r\nWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comes\nfrom hardware and the length of array is a fixed value. To void array out\nof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)",
  "id": "OESA-2024-2220",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46857"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-39482",
    "CVE-2024-41030",
    "CVE-2024-41095",
    "CVE-2024-43900",
    "CVE-2024-44958",
    "CVE-2024-44982",
    "CVE-2024-45008",
    "CVE-2024-45016",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46679",
    "CVE-2024-46681",
    "CVE-2024-46695",
    "CVE-2024-46707",
    "CVE-2024-46721",
    "CVE-2024-46725",
    "CVE-2024-46726",
    "CVE-2024-46732",
    "CVE-2024-46737",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46743",
    "CVE-2024-46750",
    "CVE-2024-46753",
    "CVE-2024-46755",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46759",
    "CVE-2024-46761",
    "CVE-2024-46771",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781",
    "CVE-2024-46791",
    "CVE-2024-46798",
    "CVE-2024-46804",
    "CVE-2024-46814",
    "CVE-2024-46816",
    "CVE-2024-46818",
    "CVE-2024-46821",
    "CVE-2024-46829",
    "CVE-2024-46833",
    "CVE-2024-46841",
    "CVE-2024-46844",
    "CVE-2024-46849",
    "CVE-2024-46857"
  ]
}