deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-42293
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: mm: Fix lockless walks with static and dynamic page-table folding

Lina reports random oopsen originating from the fast GUP code when
16K pages are used with 4-level page-tables, the fourth level being
folded at runtime due to lack of LPA2.

In this configuration, the generic implementation of
p4d_offset_lockless() will return a 'p4d_t *' corresponding to the
'pgd_t' allocated on the stack of the caller, gup_fast_pgd_range().
This is normally fine, but when the fourth level of page-table is folded
at runtime, pud_offset_lockless() will offset from the address of the
'p4d_t' to calculate the address of the PUD in the same page-table page.
This results in a stray stack read when the 'p4d_t' has been allocated
on the stack and can send the walker into the weeds.

Fix the problem by providing our own definition of p4d_offset_lockless()
when CONFIG_PGTABLE_LEVELS <= 4 which returns the real page-table
pointer rather than the address of the local stack variable.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/36639013b3462c06ff8e3400a427f775b4fc97f5; https://git.kernel.org/stable/c/78672d49d3eebbcda3589f4d6e589caf357c5a59
CVE: CVE-2024-42295
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: handle inconsistent state in nilfs_btnode_create_block()

Syzbot reported that a buffer state inconsistency was detected in
nilfs_btnode_create_block(), triggering a kernel bug.

It is not appropriate to treat this inconsistency as a bug; it can occur
if the argument block address (the buffer index of the newly created
block) is a virtual block number and has been reallocated due to
corruption of the bitmap used to manage its allocation state.

So, modify nilfs_btnode_create_block() and its callers to treat it as a
possible filesystem error, rather than triggering a kernel bug.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/012be828a118bf496e666ef1fc47fc0e7358ada2; https://git.kernel.org/stable/c/02b87e6334a38c65eef49848d3f1ac422f0b2a44; https://git.kernel.org/stable/c/19cce46238ffe3546e44b9c74057103ff8b24c62
CVE: CVE-2024-42296
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix return value of f2fs_convert_inline_inode()

If device is readonly, make f2fs_convert_inline_inode()
return EROFS instead of zero, otherwise it may trigger
panic during writeback of inline inode's dirty page as
below:

 f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888
 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline]
 __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline]
 f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369
 do_writepages+0x359/0x870 mm/page-writeback.c:2634
 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397
 __filemap_fdatawrite_range mm/filemap.c:430 [inline]
 file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788
 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276
 generic_write_sync include/linux/fs.h:2806 [inline]
 f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977
 call_write_iter include/linux/fs.h:2114 [inline]
 new_sync_write fs/read_write.c:497 [inline]
 vfs_write+0xa72/0xc90 fs/read_write.c:590
 ksys_write+0x1a0/0x2c0 fs/read_write.c:643
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/077f0e24b27c4b44841593c7edbd1993be9eecb5; https://git.kernel.org/stable/c/1e[PII_REDACTED]c8c008d131db195cef8274ff26b8; https://git.kernel.org/stable/c/47a8ddcdcaccd9b891db4574795e46a33a121ac2
CVE: CVE-2024-42297
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to don't dirty inode for readonly filesystem

syzbot reports f2fs bug as below:

kernel BUG at fs/f2fs/inode.c:933!
RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933
Call Trace:
 evict+0x2a4/0x620 fs/inode.c:664
 dispose_list fs/inode.c:697 [inline]
 evict_inodes+0x5f8/0x690 fs/inode.c:747
 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675
 kill_block_super+0x44/0x90 fs/super.c:1667
 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894
 deactivate_locked_super+0xc1/0x130 fs/super.c:484
 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256
 task_work_run+0x24a/0x300 kernel/task_work.c:180
 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399
 ptrace_report_syscall include/linux/ptrace.h:411 [inline]
 ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]
 syscall_exit_work kernel/entry/common.c:251 [inline]
 syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]
 syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296
 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

The root cause is:
- do_sys_open
 - f2fs_lookup
  - __f2fs_find_entry
   - f2fs_i_depth_write
    - f2fs_mark_inode_dirty_sync
     - f2fs_dirty_inode
      - set_inode_flag(inode, FI_DIRTY_INODE)

- umount
 - kill_f2fs_super
  - kill_block_super
   - generic_shutdown_super
    - sync_filesystem
    : sb is readonly, skip sync_filesystem()
    - evict_inodes
     - iput
      - f2fs_evict_inode
       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))
       : trigger kernel panic

When we try to repair i_current_depth in readonly filesystem, let's
skip dirty inode to avoid panic in later f2fs_evict_inode().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/192b8fb8d1c8ca3c87366ebbef599fa80bb626b8; https://git.kernel.org/stable/c/[PII_REDACTED]f6743efb3ac15d11af9a0db9543bd3; https://git.kernel.org/stable/c/2d[PII_REDACTED]f2239b3377d9e8d12da5e6ccdfcf
CVE: CVE-2024-42298
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: fsl: fsl_qmc_audio: Check devm_kasprintf() returned value

devm_kasprintf() can return a NULL pointer on failure but this returned
value is not checked.

Fix this lack and check the returned value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/af466037fa2b263e8ea5c47285513d2487e17d90; https://git.kernel.org/stable/c/b4205dfcfe96182118e[PII_REDACTED]7eda51b2135; https://git.kernel.org/stable/c/e[PII_REDACTED]7d27687693f6e5253a5d56583db58
CVE: CVE-2024-42299
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed

If an NTFS file system is mounted to another system with different
PAGE_SIZE from the original system, log->page_size will change in
log_replay(), but log->page_{mask,bits} don't change correspondingly.
This will cause a panic because "u32 bytes = log->page_size - page_off"
will get a negative value in the later read_log_page().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0484adcb5fbcadd9ba0fd4485c42630f72e97da9; https://git.kernel.org/stable/c/0a4ae2644e2a3b3b219aad9639fb2b0691d08420; https://git.kernel.org/stable/c/2cac0df3324b5e287d8020bc0708f7d2dec88a6f
CVE: CVE-2024-42300
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix race in z_erofs_get_gbuf()

In z_erofs_get_gbuf(), the current task may be migrated to another
CPU between `z_erofs_gbuf_id()` and `spin_lock(&gbuf->lock)`.

Therefore, z_erofs_put_gbuf() will trigger the following issue
which was found by stress test:

<2>[[PII_REDACTED]68] kernel BUG at fs/erofs/zutil.c:58!
..
<4>[[PII_REDACTED]07]
<4>[[PII_REDACTED]37] CPU: 0 PID: 3078 Comm: stress Kdump: loaded Tainted: G            E      6.10.0-rc7+ #2
<4>[[PII_REDACTED]39] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 1.0.0 01/01/2017
<4>[[PII_REDACTED]41] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
<4>[[PII_REDACTED]43] pc : z_erofs_put_gbuf+0x64/0x70 [erofs]
<4>[[PII_REDACTED]52] lr : z_erofs_lz4_decompress+0x600/0x6a0 [erofs]
..
<6>[[PII_REDACTED]58] stress (3127): drop_caches: 1
<4>[[PII_REDACTED]20] Call trace:
<4>[[PII_REDACTED]21]  z_erofs_put_gbuf+0x64/0x70 [erofs]
<4>[[PII_REDACTED]61]  z_erofs_lz4_decompress+0x600/0x6a0 [erofs]
<4>[[PII_REDACTED]97]  z_erofs_decompress_queue+0x740/0xa10 [erofs]
<4>[[PII_REDACTED]36]  z_erofs_runqueue+0x428/0x8c0 [erofs]
<4>[[PII_REDACTED]60]  z_erofs_readahead+0x224/0x390 [erofs]
..
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/49b22e06a947727a6d1c802d2d9ad92420b90fc5; https://git.kernel.org/stable/c/7dc5537c3f8be87e005f0844a7626c987914f8fd
CVE: CVE-2024-42301
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8; https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d; https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a
CVE: CVE-2024-42302
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal

Keith reports a use-after-free when a DPC event occurs concurrently to
hot-removal of the same portion of the hierarchy:

The dpc_handler() awaits readiness of the secondary bus below the
Downstream Port where the DPC event occurred.  To do so, it polls the
config space of the first child device on the secondary bus.  If that
child device is concurrently removed, accesses to its struct pci_dev
cause the kernel to oops.

That's because pci_bridge_wait_for_secondary_bus() neglects to hold a
reference on the child device.  Before v6.3, the function was only
called on resume from system sleep or on runtime resume.  Holding a
reference wasn't necessary back then because the pciehp IRQ thread
could never run concurrently.  (On resume from system sleep, IRQs are
not enabled until after the resume_noirq phase.  And runtime resume is
always awaited before a PCI device is removed.)

However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also
called on a DPC event.  Commit 53b54ad074de ("PCI/DPC: Await readiness
of secondary bus after reset"), which introduced that, failed to
appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a
reference on the child device because dpc_handler() and pciehp may
indeed run concurrently.  The commit was backported to v5.10+ stable
kernels, so that's the oldest one affected.

Add the missing reference acquisition.

Abridged stack trace:

  BUG: unable to handle page fault for address:[PII_REDACTED]1400c0
  CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0
  RIP: pci_bus_read_config_dword+0x17/0x50
  pci_dev_wait()
  pci_bridge_wait_for_secondary_bus()
  dpc_reset_link()
  pcie_do_recovery()
  dpc_handler()
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/11a1f4bc47362700fcbde[PII_REDACTED]73fb847ed; https://git.kernel.org/stable/c/2c111413f38ca5cf87557cab89f6d82b0e3433e7; https://git.kernel.org/stable/c/2cc8973bdc4d6c928ebe38b88090a2cdfe81f42f
CVE: CVE-2024-42303
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: imx-pxp: Fix ERR_PTR dereference in pxp_probe()

devm_regmap_init_mmio() can fail, add a check and bail out in case of
error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/358bc85269d6a359fea597ef9fbb429cd3626e08; https://git.kernel.org/stable/c/57e9ce68ae98551da9c161aaab12b41fe8601856; https://git.kernel.org/stable/c/5ab6ac4e9e165b0fe8a[PII_REDACTED]37007224f05
CVE: CVE-2024-42304
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: make sure the first directory block is not a hole

The syzbot constructs a directory that has no dirblock but is non-inline,
i.e. the first directory block is a hole. And no errors are reported when
creating files in this directory in the following flow.

    ext4_mknod
     ...
      ext4_add_entry
        // Read block 0
        ext4_read_dirblock(dir, block, DIRENT)
          bh = ext4_bread(NULL, inode, block, 0)
          if (!bh && (type == INDEX || type == DIRENT_HTREE))
          // The first directory block is a hole
          // But type == DIRENT, so no error is reported.

After that, we get a directory block without '.' and '..' but with a valid
dentry. This may cause some code that relies on dot or dotdot (such as
make_indexed_dir()) to crash.

Therefore when ext4_read_dirblock() finds that the first directory block
is a hole report that the filesystem is corrupted and return an error to
avoid loading corrupted data from disk causing something bad.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/299bc6ffa57e04e74c6cce866d6c0741fb4897a1; https://git.kernel.org/stable/c/9771e3d8365ae1dd5e8846a204cb9af14e3e656a; https://git.kernel.org/stable/c/b609753cbbd38f8c0affd4956c0af178348523ac
CVE: CVE-2024-42305
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:
============================================
BUG: unable to handle page fault for address: ffffed11022e24fe
PGD 23ffee067 P4D 23ffee067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0
Call Trace:
 <TASK>
 make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341
 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451
 ext4_rename fs/ext4/namei.c:3936 [inline]
 ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214
[...]
============================================

The immediate cause of this problem is that there is only one valid dentry
for the block to be split during do_split, so split==0 results in out of
bounds accesses to the map triggering the issue.

    do_split
      unsigned split
      dx_make_map
       count = 1
      split = count/2 = 0;
      continued = hash2 == map[split - 1].hash;
       ---> map[[PII_REDACTED]]

The maximum length of a filename is 255 and the minimum block size is 1024,
so it is always guaranteed that the number of entries is greater than or
equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry
distribution in dirblock is as follows:

  bus     dentry1          hole           dentry2           free
|xx--|xx-------------|...............|xx-------------|...............|
0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024

So when renaming dentry1 increases its name_len length by 1, neither hole
nor free is sufficient to hold the new dentry, and make_indexed_dir() is
called.

In make_indexed_dir() it is assumed that the first two entries of the
dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root
because they are treated as dot and dotdot, and only dentry2 is moved
to the new leaf block. That's why count is equal to 1.

Therefore add the ext4_check_dx_root() helper function to add more sanity
checks to dot and dotdot before starting the conversion to avoid the above
issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/19e13b4d7f0303186fcc891aba8d0de7c8fdbda8; https://git.kernel.org/stable/c/42d[PII_REDACTED]28fb0eb852c358056b7717ba5aa; https://git.kernel.org/stable/c/50ea741def587a64e08879ce6c6a30131f7111e7
CVE: CVE-2024-42306
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption
while loading the bitmap and fail the allocation with error. However the
next allocation from the same bitmap will notice the bitmap buffer is
already loaded and tries to allocate from the bitmap with mixed results
(depending on the exact nature of the bitmap corruption). Fix the
problem by using BH_verified bit to indicate whether the bitmap is valid
or not.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2199e157a465aaf98294d3932797ecd7fce942d5; https://git.kernel.org/stable/c/271cab2ca00652bc984e269cf1208699a1e09cdd; https://git.kernel.org/stable/c/57053b3bcf3403b80db6f65aba284d7dfe7326af
CVE: CVE-2024-42307
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path

Dan Carpenter reported a Smack static checker warning:
   fs/smb/client/cifsfs.c:1981 init_cifs()
   error: we previously assumed 'serverclose_wq' could be null (see line 1895)

The patch which introduced the serverclose workqueue used the wrong
oredering in error paths in init_cifs() for freeing it on errors.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/160235efb4f9b55212dedff5de0094c606c4b303; https://git.kernel.org/stable/c/193cc89ea0ca1da311877d2b4bb5e9f03bcc82a2; https://git.kernel.org/stable/c/3739d711246d8fbc95ff73dbdace9741cdce4777
CVE: CVE-2024-42308
Published: 2024-08-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-42309
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes

In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee; https://git.kernel.org/stable/c/2df7aac81070987b0f052985856aa325a38debf6; https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692
CVE: CVE-2024-42310
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes

In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/08f45102c81ad8bc9f85f7a25e9f64e128edb87d; https://git.kernel.org/stable/c/2d209b2f862f6b8bff549ede541590a8d119da23; https://git.kernel.org/stable/c/977ee4fe895e1729cd36cc26916bbb10084713d6
CVE: CVE-2024-42312
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

sysctl: always initialize i_uid/i_gid

Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/1deae34db9f4f8e0e03f891be2e2e15c15c8ac05; https://git.kernel.org/stable/c/34a86adea1f2b3c3f9d864c8cce09dca644601ab; https://git.kernel.org/stable/c/98ca62ba9e2be5863c7d069f84f7166b45a5b2f4
CVE: CVE-2024-42313
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close().
The firmware will add buffer release work to the work queue through
HFI callbacks as a normal part of decoding. Randomly closing the
decoder device from userspace during normal decoding can incur
a read after free for inst.

Fix it by cancelling the work in vdec_close.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36; https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635; https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d63920c2
CVE: CVE-2024-42314
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix extent map use-after-free when adding pages to compressed bio

At add_ra_bio_pages() we are accessing the extent map to calculate
'add_size' after we dropped our reference on the extent map, resulting
in a use-after-free. Fix this by computing 'add_size' before dropping our
extent map reference.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/8e7860543a94784d744c7ce34b78a2e11beefa5c; https://git.kernel.org/stable/c/b7859ff398b6b656e1689daa860eb34837b4bb89; https://git.kernel.org/stable/c/c1cc3326e27b0bd7a2806b40bc48e49afaf951e7
CVE: CVE-2024-42315
Published: 2024-08-17
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix potential deadlock on __exfat_get_dentry_set

When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array
is allocated in __exfat_get_entry_set. The problem is that the bh-array is
allocated with GFP_KERNEL. It does not make sense. In the following cases,
a deadlock for sbi->s_lock between the two processes may occur.

       CPU0                CPU1
       ----                ----
  kswapd
   balance_pgdat
    lock(fs_reclaim)
                      exfat_iterate
                       lock(&sbi->s_lock)
                       exfat_readdir
                        exfat_get_uniname_from_ext_entry
                         exfat_get_dentry_set
                          __exfat_get_dentry_set
                           kmalloc_array
                            ...
                            lock(fs_reclaim)
    ...
    evict
     exfat_evict_inode
      lock(&sbi->s_lock)

To fix this, let's allocate bh-array with GFP_NOFS.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62; https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb; https://git.kernel.org/stable/c/89fc548767a[PII_REDACTED]cb98726d6d2ea1256c9