deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-40935
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: flush all requests after setting CACHEFILES_DEAD

In ondemand mode, when the daemon is processing an open request, if the
kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write()
will always return -EIO, so the daemon can't pass the copen to the kernel.
Then the kernel process that is waiting for the copen triggers a hung_task.

Since the DEAD state is irreversible, it can only be exited by closing
/dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark
the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to
avoid the above hungtask. We may still be able to read some of the cached
data before closing the fd of /dev/cachefiles.

Note that this relies on the patch that adds reference counting to the req,
otherwise it may UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/320ba9cbca78be79c912143bbba1d1b35ca55cf0; https://git.kernel.org/stable/c/3bf0b8030296e9ee60d3d4c15849ad9ac0b47081; https://git.kernel.org/stable/c/85e833cd7243bda7285492b0653c3abb1e2e757b
CVE: CVE-2024-40936
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/region: Fix memregion leaks in devm_cxl_add_region()

Move the mode verification to __create_region() before allocating the
memregion to avoid the memregion leaks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/49ba7b515c4c0719b866d16f068e62d16a8a3dd1; https://git.kernel.org/stable/c/bbb5d8746381c82f7e0fb6171094d375b492f266; https://git.kernel.org/stable/c/d8316838aa0686da63a8be4194b7a17b0103ae4a
CVE: CVE-2024-40937
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

gve: Clear napi->skb before dev_kfree_skb_any()

gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it
is freed with dev_kfree_skb_any(). This can result in a subsequent call
to napi_get_frags returning a dangling pointer.

Fix this by clearing napi->skb before the skb is freed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2ce5341c36993b[PII_REDACTED]21d7688693f8c037; https://git.kernel.org/stable/c/6f4d93b78ade0a4c2cafd587f7b429ce95abb02e; https://git.kernel.org/stable/c/75afd8724739ee5ed8165acde5f6ac3988b485cc
CVE: CVE-2024-40938
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

landlock: Fix d_parent walk

The WARN_ON_ONCE() in collect_domain_accesses() can be triggered when
trying to link a root mount point.  This cannot work in practice because
this directory is mounted, but the VFS check is done after the call to
security_path_link().

Do not use source directory's d_parent when the source directory is the
mount point.

[mic: Fix commit message]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/88da52ccd66e65f2e63a6c35c9dff55d448ef4dc; https://git.kernel.org/stable/c/b6e5e696435832b33e40775f060ef5c95f4fda1f; https://git.kernel.org/stable/c/c7618c7b0b8c45bcef34410cc1d1e953eb17f8f6
CVE: CVE-2024-40939
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: wwan: iosm: Fix tainted pointer delete is case of region creation fail

In case of region creation fail in ipc_devlink_create_region(), previously
created regions delete process starts from tainted pointer which actually
holds error code value.
Fix this bug by decreasing region index before delete.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/040d[PII_REDACTED]eb5dc55472ac573ac7756b2050; https://git.kernel.org/stable/c/37a438704d19bdbe246d51d3749b6b3a8fe65afd; https://git.kernel.org/stable/c/b0c9a26435413b81799047a7be[PII_REDACTED]2547
CVE: CVE-2024-40940
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix tainted pointer delete is case of flow rules creation fail

In case of flow rule creation fail in mlx5_lag_create_port_sel_table(),
instead of previously created rules, the tainted pointer is deleted
deveral times.
Fix this bug by using correct flow rules pointers.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/229bedbf62b13af5aba6525ad10b62ad38d9ccb5; https://git.kernel.org/stable/c/531eab2da27dd42d68dfb841d82e987f4a6738b8; https://git.kernel.org/stable/c/a03a3fa12769e25f4385bee587afe1445aee7f7a
CVE: CVE-2024-40941
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data
than it has, we will read past that was allocated for the notification.
Remove the print of the buffer, we won't see it by default. If needed,
we can see the content with tracing.

This was reported by KFENCE.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/15b37c6fab9d5e40ac399fa1c725118588ed649c; https://git.kernel.org/stable/c/46c59a25337049a2a230ce7f7c3b9f21d0aaaad7; https://git.kernel.org/stable/c/4bb95f4535489ed830cf9b34b0a891e384d1aee4
CVE: CVE-2024-40942
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects

The hwmp code use objects of type mesh_preq_queue, added to a list in
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
gets deleted, ex mesh interface is removed, the entries in that list will
never get cleaned. Fix this by flushing all corresponding items of the
preq_queue in mesh_path_flush_pending().

This should take care of KASAN reports like this:

unreferenced object 0xffff00000668d800 (size 128):
  comm "kworker/u8:4", pid 67, jiffies[PII_REDACTED] (age 1836.444s)
  hex dump (first 32 bytes):
    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....
    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....>...........
  backtrace:
    [<[PII_REDACTED]02a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
    [<[PII_REDACTED]9bd418>] kmalloc_trace+0x34/0x80
    [<[PII_REDACTED]d792bb>] mesh_queue_preq+0x44/0x2a8
    [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
    [<[PII_REDACTED]6bf598>] ieee80211_xmit+0x1d0/0x1f4
    [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
    [<[PII_REDACTED]26ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
    [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
    [<[PII_REDACTED]>] __dev_queue_xmit+0xe24/0x111c
    [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
    [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
    [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
    [<00000000b36425d1>] worker_thread+0x9c/0x634
    [<[PII_REDACTED]852dd5>] kthread+0x1bc/0x1c4
    [<000000005fccd770>] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
  comm "kworker/u8:4", pid 67, jiffies[PII_REDACTED] (age 1836.440s)
  hex dump (first 32 bytes):
    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....
    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6'.......Xy.....
  backtrace:
    [<[PII_REDACTED]02a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
    [<[PII_REDACTED]9bd418>] kmalloc_trace+0x34/0x80
    [<[PII_REDACTED]d792bb>] mesh_queue_preq+0x44/0x2a8
    [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
    [<[PII_REDACTED]6bf598>] ieee80211_xmit+0x1d0/0x1f4
    [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
    [<[PII_REDACTED]26ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
    [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
    [<[PII_REDACTED]>] __dev_queue_xmit+0xe24/0x111c
    [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
    [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
    [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
    [<00000000b36425d1>] worker_thread+0x9c/0x634
    [<[PII_REDACTED]852dd5>] kthread+0x1bc/0x1c4
    [<000000005fccd770>] ret_from_fork+0x10/0x20
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/377dbb220edc8421b[PII_REDACTED]c5b3bef62f89b; https://git.kernel.org/stable/c/617dadbfb2d3e152c5753e28356d189c9d6f33c0; https://git.kernel.org/stable/c/63d5f89bb5664d60edbf8cf0df911aaae8ed96a4
CVE: CVE-2024-40943
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix races between hole punching and AIO+DIO

After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
fstests/generic/300 become from always failed to sometimes failed:

========================================================================
[  473.293420 ] run fstests generic/300

[  475.296983 ] JBD2: Ignoring recovery information on journal
[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
[  494.292018 ] OCFS2: File system is now read-only.
[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
=========================================================================

In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
extents to a list.  extents are also inserted into extent tree in
ocfs2_write_begin_nolock.  Then another thread call fallocate to puch a
hole at one of the unwritten extent.  The extent at cpos was removed by
ocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list
found there is no such extent at the cpos.

    T1                        T2                T3
                              inode lock
                                ...
                                insert extents
                                ...
                              inode unlock
ocfs2_fallocate
 __ocfs2_change_file_space
  inode lock
  lock ip_alloc_sem
  ocfs2_remove_inode_range inode
   ocfs2_remove_btree_range
    ocfs2_remove_extent
    ^---remove the extent at cpos 78723
  ...
  unlock ip_alloc_sem
  inode unlock
                                       ocfs2_dio_end_io
                                        ocfs2_dio_end_io_write
                                         lock ip_alloc_sem
                                         ocfs2_mark_extent_written
                                          ocfs2_change_extent_flag
                                           ocfs2_search_extent_list
                                           ^---failed to find extent
                                          ...
                                          unlock ip_alloc_sem

In most filesystems, fallocate is not compatible with racing with AIO+DIO,
so fix it by adding to wait for all dio before fallocate/punch_hole like
ext4.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/050ce8af6838c71e872e982b50d3f1bec21da40e; https://git.kernel.org/stable/c/117b9c009b72a6c2ebfd23484354dfee2d9570d2; https://git.kernel.org/stable/c/38825ff9da91d2854dcf6d9ac320a7e641e10f25
CVE: CVE-2024-40944
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/kexec: Fix bug with call depth tracking

The call to cc_platform_has() triggers a fault and system crash if call depth
tracking is active because the GS segment has been reset by load_segments() and
GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate.

Call cc_platform_has() earlier in the function when GS is still valid.

  [ bp: Massage. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2cfb464669b645a9b98478b74f2bcea9860dcff1; https://git.kernel.org/stable/c/93c1800b3799f17375989b0daf76497dd3e80922; https://git.kernel.org/stable/c/d91ddd05082691e69b30744825d18ae799293258
CVE: CVE-2024-40945
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu: Return right value in iommu_sva_bind_device()

iommu_sva_bind_device() should return either a sva bond handle or an
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
check the return value with IS_ERR(). This could potentially lead to
a kernel NULL pointer dereference issue if the function returns NULL
instead of an error pointer.

In reality, this doesn't cause any problems because iommu_sva_bind_device()
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
return an error, and the device drivers won't call iommu_sva_bind_device()
at all.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b[PII_REDACTED]; https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e; https://git.kernel.org/stable/c/6325eab6c108fed27f60ff51852e3eac0ba23f3f
CVE: CVE-2024-40946
Published: 2024-07-12
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-40948
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/page_table_check: fix crash on ZONE_DEVICE

Not all pages may apply to pgtable check.  One example is ZONE_DEVICE
pages: they map PFNs directly, and they don't allocate page_ext at all
even if there's struct page around.  One may reference
devm_memremap_pages().

When both ZONE_DEVICE and page-table-check enabled, then try to map some
dax memories, one can trigger kernel bug constantly now when the kernel
was trying to inject some pfn maps on the dax device:

 kernel BUG at mm/page_table_check.c:55!

While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page
fault resolutions, skip all the checks if page_ext doesn't even exist in
pgtable checker, which applies to ZONE_DEVICE but maybe more.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/51897f99351fff7b57f4f141940fa93b4e90fd2b; https://git.kernel.org/stable/c/84d3549d54f5ff9fa3281257be3019386f51d1a0; https://git.kernel.org/stable/c/8bb592c2eca8fd2bc06db7d80b38da18da4a2f43
CVE: CVE-2024-40950
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: huge_memory: fix misused mapping_large_folio_support() for anon folios

When I did a large folios split test, a WARNING "[ 5059.122759][ T166]
Cannot split file folio to non-0 order" was triggered.  But the test cases
are only for anonmous folios.  while mapping_large_folio_support() is only
reasonable for page cache folios.

In split_huge_page_to_list_to_order(), the folio passed to
mapping_large_folio_support() maybe anonmous folio.  The folio_test_anon()
check is missing.  So the split of the anonmous THP is failed.  This is
also the same for shmem_mapping().  We'd better add a check for both.  But
the shmem_mapping() in __split_huge_page() is not involved, as for
anonmous folios, the end parameter is set to -1, so (head[i].index >= end)
is always false.  shmem_mapping() is not called.

Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon
mapping, So we can detect the wrong use more easily.

THP folios maybe exist in the pagecache even the file system doesn't
support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is
enabled, khugepaged will try to collapse read-only file-backed pages to
THP.  But the mapping does not actually support multi order large folios
properly.

Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,
large anon THP is successfully split and the warning is ceased.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c; https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a; https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c
CVE: CVE-2024-40951
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()

bdev->bd_super has been removed and commit 8887b94d9322 change the usage
from bdev->bd_super to b_assoc_map->host->i_sb.  Since ocfs2 hasn't set
bh->b_assoc_map, it will trigger NULL pointer dereference when calling
into ocfs2_abort_trigger().

Actually this was pointed out in history, see commit 74e364ad1b13.  But
I've made a mistake when reviewing commit 8887b94d9322 and then
re-introduce this regression.

Since we cannot revive bdev in buffer head, so fix this issue by
initializing all types of ocfs2 triggers when fill super, and then get the
specific ocfs2 trigger from ocfs2_caching_info when access journal.

[joseph.qi@linux.alibaba.com: v2]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/67bcecd780609f471260a8c83fb0ae15f27734ce; https://git.kernel.org/stable/c/685d03c3795378fca6a1b3d43581f7f1a3fc095f; https://git.kernel.org/stable/c/eb63357ef229fae061ce7ce2839d558681c42f1a
CVE: CVE-2024-40953
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()

Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it's theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:

  CPU0                              CPU1
  last_boosted_vcpu = 0xff;

                                    (last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;

  vcpu = kvm->vcpu_array[0x1ff];

As detected by KCSAN:

  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]

  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  x64_sys_call (arch/x86/entry/syscall_64.c:33)
  do_syscall_64 (arch/x86/entry/common.c:?)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

  read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
			arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  x64_sys_call (arch/x86/entry/syscall_64.c:33)
  do_syscall_64 (arch/x86/entry/common.c:?)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

  value changed: 0x00000012 -> 0x00000000
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/11a772d5376aa6d3e2e69b5b5c585f79b60c0e17; https://git.kernel.org/stable/c/49f683b41f28918df3e51ddc0d928cb2e934ccdb; https://git.kernel.org/stable/c/4c141136a28421b78f34969b25a4fa32e06e2180
CVE: CVE-2024-40955
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()

We can trigger a slab-out-of-bounds with the following commands:

    mkfs.ext4 -F /dev/$disk 10G
    mount /dev/$disk /tmp/test
    echo[PII_REDACTED] > /sys/fs/ext4/$disk/mb_group_prealloc
    echo test > /tmp/test/file && sync

==================================================================
BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]
Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11
CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521
Call Trace:
 dump_stack_lvl+0x2c/0x50
 kasan_report+0xb6/0xf0
 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]
 ext4_mb_regular_allocator+0x19e9/0x2370 [ext4]
 ext4_mb_new_blocks+0x88a/0x1370 [ext4]
 ext4_ext_map_blocks+0x14f7/0x2390 [ext4]
 ext4_map_blocks+0x569/0xea0 [ext4]
 ext4_do_writepages+0x10f6/0x1bc0 [ext4]
[...]
==================================================================

The flow of issue triggering is as follows:

// Set s_mb_group_prealloc to[PII_REDACTED] via sysfs
ext4_mb_new_blocks
  ext4_mb_normalize_request
    ext4_mb_normalize_group_request
      ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc
  ext4_mb_regular_allocator
    ext4_mb_choose_next_group
      ext4_mb_choose_next_group_best_avail
        mb_avg_fragment_size_order
          order = fls(len) - 2 = 29
        ext4_mb_find_good_group_avg_frag_lists
          frag_list = &sbi->s_mb_avg_fragment_size[order]
          if (list_empty(frag_list)) // Trigger SOOB!

At 4k block size, the length of the s_mb_avg_fragment_size list is 14,
but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds
to be triggered by an attempt to access an element at index 29.

Add a new attr_id attr_clusters_in_group with values in the range
[0, sbi->s_clusters_per_group] and declare mb_group_prealloc as
that type to fix the issue. In addition avoid returning an order
from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb)
and reduce some useless loops.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/13df4d44a3aaabe61cd01d277b6ee23ead2a5206; https://git.kernel.org/stable/c/677ff4589f1501578fa903a25bb14831d0607992; https://git.kernel.org/stable/c/b829687ae[PII_REDACTED]bcabf49accfa2dbf8db06
CVE: CVE-2024-40956
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list

Use list_for_each_entry_safe() to allow iterating through the list and
deleting the entry in the iteration process. The descriptor is freed via
idxd_desc_complete() and there's a slight chance may cause issue for
the list iterator when the descriptor is reused by another thread
without it being deleted from the list.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33; https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5; https://git.kernel.org/stable/c/a[PII_REDACTED]793f2a956086895c[PII_REDACTED]dd