deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26956
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix failure to detect DAT corruption in btree and direct mappings

Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".

This resolves a kernel BUG reported by syzbot.  Since there are two
flaws involved, I've made each one a separate patch.

The first patch alone resolves the syzbot-reported bug, but I think
both fixes should be sent to stable, so I've tagged them as such.


This patch (of 2):

Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
to a nilfs2 file system whose metadata is corrupted.

There are two flaws involved in this issue.

The first flaw is that when nilfs_get_block() locates a data block using
btree or direct mapping, if the disk address translation routine
nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
corruption, it can be passed back to nilfs_get_block().  This causes
nilfs_get_block() to misidentify an existing block as non-existent,
causing both data block lookup and insertion to fail inconsistently.

The second flaw is that nilfs_get_block() returns a successful status in
this inconsistent state.  This causes the caller __block_write_begin_int()
or others to request a read even though the buffer is not mapped,
resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
failing.

This fixes the first issue by changing the return value to code -EINVAL
when a conversion using DAT fails with code -ENOENT, avoiding the
conflicting condition that leads to the kernel bug described above.  Here,
code -EINVAL indicates that metadata corruption was detected during the
block lookup, which will be properly handled as a file system error and
converted to -EIO when passing through the nilfs2 bmap layer.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84; https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7; https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
CVE: CVE-2024-26958
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
 <TASK>
 ? __warn+0x9f/0x130
 ? refcount_warn_saturate+0x9c/0xe0
 ? report_bug+0xcc/0x150
 ? handle_bug+0x3d/0x70
 ? exc_invalid_op+0x16/0x40
 ? asm_exc_invalid_op+0x16/0x20
 ? refcount_warn_saturate+0x9c/0xe0
 nfs_direct_write_schedule_work+0x237/0x250 [nfs]
 process_one_work+0x12f/0x4a0
 worker_thread+0x14e/0x3b0
 ? ZSTD_getCParams_internal+0x220/0x220
 kthread+0xdc/0x120
 ? __btf_name_valid+0xa0/0xa0
 ret_from_fork+0x1f/0x30

This is because we're completing the nfs_direct_request twice in a row.

The source of this is when we have our commit requests to submit, we
process them and send them off, and then in the completion path for the
commit requests we have

if (nfs_commit_end(cinfo.mds))
	nfs_direct_write_complete(dreq);

However since we're submitting asynchronous requests we sometimes have
one that completes before we submit the next one, so we end up calling
complete on the nfs_direct_request twice.

The only other place we use nfs_generic_commit_list() is in
__nfs_commit_inode, which wraps this call in a

nfs_commit_begin();
nfs_commit_end();

Which is a common pattern for this style of completion handling, one
that is also repeated in the direct code with get_dreq()/put_dreq()
calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop
every 10ish minutes.  With my patch the stress test has been running for
several hours without popping.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af; https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab; https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3
CVE: CVE-2024-26959
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btnxpuart: Fix btnxpuart_close

Fix scheduling while atomic BUG in btnxpuart_close(), properly
purge the transmit queue and free the receive skb.

[   10.973809] BUG: scheduling while atomic: kworker/u9:0/80/0x00000002
...
[   10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 Not tainted 6.8.0-rc7-0.0.0-devel-00005-g61fdfceacf09 #1
[   10.980751] Hardware name: Toradex Verdin AM62 WB on Dahlia Board (DT)
[   10.980760] Workqueue: hci0 hci_power_off [bluetooth]
[   10.981169] Call trace:
...
[   10.981363]  uart_update_mctrl+0x58/0x78
[   10.981373]  uart_dtr_rts+0x104/0x114
[   10.981381]  tty_port_shutdown+0xd4/0xdc
[   10.981396]  tty_port_close+0x40/0xbc
[   10.981407]  uart_close+0x34/0x9c
[   10.981414]  ttyport_close+0x50/0x94
[   10.981430]  serdev_device_close+0x40/0x50
[   10.981442]  btnxpuart_close+0x24/0x98 [btnxpuart]
[   10.981469]  hci_dev_close_sync+0x2d8/0x718 [bluetooth]
[   10.981728]  hci_dev_do_close+0x2c/0x70 [bluetooth]
[   10.981862]  hci_power_off+0x20/0x64 [bluetooth]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/586e099c93fe26b7bd[PII_REDACTED]2f507ed9f6a4; https://git.kernel.org/stable/c/664130c0b0309b360bc5bdd40a30604a9387bde8; https://git.kernel.org/stable/c/74bcf708775c405f7fb6ed776ccd3e1957f38a52
CVE: CVE-2024-26960
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: swap: fix race between free_swap_and_cache() and swapoff()

There was previously a theoretical window where swapoff() could run and
teardown a swap_info_struct while a call to free_swap_and_cache() was
running in another thread.  This could cause, amongst other bad
possibilities, swap_page_trans_huge_swapped() (called by
free_swap_and_cache()) to access the freed memory for swap_map.

This is a theoretical problem and I haven't been able to provoke it from a
test case.  But there has been agreement based on code review that this is
possible (see link below).

Fix it by using get_swap_device()/put_swap_device(), which will stall
swapoff().  There was an extra check in _swap_info_get() to confirm that
the swap entry was not free.  This isn't present in get_swap_device()
because it doesn't make sense in general due to the race between getting
the reference and swapoff.  So I've added an equivalent check directly in
free_swap_and_cache().

Details of how to provoke one possible issue (thanks to David Hildenbrand
for deriving this):

--8<-----

__swap_entry_free() might be the last user and result in
"count == SWAP_HAS_CACHE".

swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.

So the question is: could someone reclaim the folio and turn
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().

Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
still references by swap entries.

Process 1 still references subpage 0 via swap entry.
Process 2 still references subpage 1 via swap entry.

Process 1 quits. Calls free_swap_and_cache().
-> count == SWAP_HAS_CACHE
[then, preempted in the hypervisor etc.]

Process 2 quits. Calls free_swap_and_cache().
-> count == SWAP_HAS_CACHE

Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
__try_to_reclaim_swap().

__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
swap_entry_free()->swap_range_free()->
...
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);

What stops swapoff to succeed after process 2 reclaimed the swap cache
but before process1 finished its call to swap_page_trans_huge_swapped()?

--8<-----
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a; https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a; https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
CVE: CVE-2024-26961
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mac802154: fix llsec key resources release in mac802154_llsec_key_del

mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:

refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
 <TASK>
 llsec_lookup_key.isra.0+0x890/0x9e0
 mac802154_llsec_encrypt+0x30c/0x9c0
 ieee802154_subif_start_xmit+0x24/0x1e0
 dev_hard_start_xmit+0x13e/0x690
 sch_direct_xmit+0x2ae/0xbc0
 __dev_queue_xmit+0x11dd/0x3c20
 dgram_sendmsg+0x90b/0xd60
 __sys_sendto+0x466/0x4c0
 __x64_sys_sendto+0xe0/0x1c0
 do_syscall_64+0x45/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Also, ieee802154_llsec_key_entry structures are not freed by
mac802154_llsec_key_del():

unreferenced object 0xffff8880613b6980 (size 64):
  comm "iwpan", pid 2176, jiffies[PII_REDACTED] (age 60.475s)
  hex dump (first 32 bytes):
    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......".......
    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................
  backtrace:
    [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0
    [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0
    [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0
    [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80
    [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0
    [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0
    [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0
    [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440
    [<ffffffff86ff1d88>] genl_rcv+0x28/0x40
    [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820
    [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60
    [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0
    [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0
    [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0
    [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0
    [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76

Handle the proper resource release in the RCU callback function
mac802154_llsec_key_del_rcu().

Note that if llsec_lookup_key() finds a key, it gets a refcount via
llsec_key_get() and locally copies key id from key_entry (which is a
list element). So it's safe to call llsec_key_put() and free the list
entry after the RCU grace period elapses.

Found by Linux Verification Center (linuxtesting.org).
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531; https://git.kernel.org/stable/c/20d3e1c8a[PII_REDACTED]f04d874b2a5818ec29e2d; https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1
CVE: CVE-2024-26962
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape

For raid456, if reshape is still in progress, then IO across reshape
position will wait for reshape to make progress. However, for dm-raid,
in following cases reshape will never make progress hence IO will hang:

1) the array is read-only;
2) MD_RECOVERY_WAIT is set;
3) MD_RECOVERY_FROZEN is set;

After commit c467e97f079f ("md/raid6: use valid sector values to determine
if an I/O should wait on the reshape") fix the problem that IO across
reshape position doesn't wait for reshape, the dm-raid test
shell/lvconvert-raid-reshape.sh start to hang:

[root@fedora ~]# cat /proc/979/stack
[<0>] wait_woken+0x7d/0x90
[<0>] raid5_make_request+0x929/0x1d70 [raid456]
[<0>] md_handle_request+0xc2/0x3b0 [md_mod]
[<0>] raid_map+0x2c/0x50 [dm_raid]
[<0>] __map_bio+0x251/0x380 [dm_mod]
[<0>] dm_submit_bio+0x1f0/0x760 [dm_mod]
[<0>] __submit_bio+0xc2/0x1c0
[<0>] submit_bio_noacct_nocheck+0x17f/0x450
[<0>] submit_bio_noacct+0x2bc/0x780
[<0>] submit_bio+0x70/0xc0
[<0>] mpage_readahead+0x169/0x1f0
[<0>] blkdev_readahead+0x18/0x30
[<0>] read_pages+0x7c/0x3b0
[<0>] page_cache_ra_unbounded+0x1ab/0x280
[<0>] force_page_cache_ra+0x9e/0x130
[<0>] page_cache_sync_ra+0x3b/0x110
[<0>] filemap_get_pages+0x143/0xa30
[<0>] filemap_read+0xdc/0x4b0
[<0>] blkdev_read_iter+0x75/0x200
[<0>] vfs_read+0x272/0x460
[<0>] ksys_read+0x7a/0x170
[<0>] __x64_sys_read+0x1c/0x30
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

This is because reshape can't make progress.

For md/raid, the problem doesn't exist because register new sync_thread
doesn't rely on the IO to be done any more:

1) If array is read-only, it can switch to read-write by ioctl/sysfs;
2) md/raid never set MD_RECOVERY_WAIT;
3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold
   'reconfig_mutex', hence it can be cleared and reshape can continue by
   sysfs api 'sync_action'.

However, I'm not sure yet how to avoid the problem in dm-raid yet. This
patch on the one hand make sure raid_message() can't change
sync_thread() through raid_message() after presuspend(), on the other
hand detect the above 3 cases before wait for IO do be done in
dm_suspend(), and let dm-raid requeue those IO.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677; https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1; https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304
CVE: CVE-2024-26963
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3-am62: fix module unload/reload behavior

As runtime PM is enabled, the module can be runtime
suspended when .remove() is called.

Do a pm_runtime_get_sync() to make sure module is active
before doing any register operations.

Doing a pm_runtime_put_sync() should disable the refclk
so no need to disable it again.

Fixes the below warning at module removel.

[   39.705310] ------------[ cut here ]------------
[   39.710004] clk:162:3 already disabled
[   39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8

We called of_platform_populate() in .probe() so call the
cleanup function of_platform_depopulate() in .remove().
Get rid of the now unnnecessary dwc3_ti_remove_core().
Without this, module re-load doesn't work properly.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3895780fabd120d0fbd54354014e85207b25687c; https://git.kernel.org/stable/c/629b534c42d04f0797980f2d1ed105fdb8906975; https://git.kernel.org/stable/c/6661befe41009c210efa2c1bcd16a5cc4cff8a06
CVE: CVE-2024-26964
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Add error handling in xhci_map_urb_for_dma

Currently xhci_map_urb_for_dma() creates a temporary buffer and copies
the SG list to the new linear buffer. But if the kzalloc_node() fails,
then the following sg_pcopy_to_buffer() can lead to crash since it
tries to memcpy to NULL pointer.

So return -ENOMEM if kzalloc returns null pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd; https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4; https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757
CVE: CVE-2024-26965
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060; https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589; https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362
CVE: CVE-2024-26966
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99; https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9; https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2
CVE: CVE-2024-26967
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: camcc-sc8280xp: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/6a3d70f7802a98e6c28a74f997a264118b9f50cd; https://git.kernel.org/stable/c/93ff48729211dae55df5d216023be4528d29babb; https://git.kernel.org/stable/c/6a3d70f7802a98e6c28a74f997a264118b9f50cd
CVE: CVE-2024-26968
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq9574: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/0204247cf3669b6021fb745c3b7f37ae392ab19c; https://git.kernel.org/stable/c/1723629fea8a4e[PII_REDACTED]6e10d395463dca72; https://git.kernel.org/stable/c/604f2d7c46727c5e24fc7faddc980bc1cc0b1011
CVE: CVE-2024-26969
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429; https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94; https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe
CVE: CVE-2024-26970
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52; https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb; https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6
CVE: CVE-2024-26971
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq5018: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/50c3acd460551cdf9d8ac6fe0c04f2de0e8e0872; https://git.kernel.org/stable/c/90ad946fff70f312b8d23226afc38c13ddd88c4b; https://git.kernel.org/stable/c/b0cf3d200e8a72b6d28e6e088c062b4a98cb5eaf
CVE: CVE-2024-26972
Published: 2024-05-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26973
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

fat: fix uninitialized field in nostale filehandles

When fat_encode_fh_nostale() encodes file handle without a parent it
stores only first 10 bytes of the file handle. However the length of the
file handle must be a multiple of 4 so the file handle is actually 12
bytes long and the last two bytes remain uninitialized. This is not
great at we potentially leak uninitialized information with the handle
to userspace. Properly initialize the full handle length.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb; https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3386c688; https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63
CVE: CVE-2024-26974
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.

This results in a KFENCE bug notice.

  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
  adf_device_reset_worker+0x38/0xa0 [intel_qat]
  process_one_work+0x173/0x340

To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function.
CVSS Score: 7.0 (HIGH)
CWE: CWE-367, CWE-416
References: https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be; https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7; https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c[PII_REDACTED]815b64ca4f