deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-36270
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: tproxy: bail out if IP has been disabled on the device

syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000018-0x[PII_REDACTED]00001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
 nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
 nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168

__in_dev_get_rcu() can return NULL, so check for this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/07eeedafc59c45fe5de[PII_REDACTED]2be3784764c; https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d; https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3
CVE: CVE-2024-36281
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules

rx_create no longer allocates a modify_hdr instance that needs to be
cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer
dereference. A leak in the rules also previously occurred since there are
now two rules populated related to status.

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 109907067 P4D 109907067 PUD 116890067 PMD 0
  Oops: 0000 [#1] SMP
  CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014
  RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70
  <snip>
  Call Trace:
   <TASK>
   ? show_regs+0x60/0x70
   ? __die+0x24/0x70
   ? page_fault_oops+0x15f/0x430
   ? free_to_partial_list.constprop.0+0x79/0x150
   ? do_user_addr_fault+0x2c9/0x5c0
   ? exc_page_fault+0x63/0x110
   ? asm_exc_page_fault+0x27/0x30
   ? mlx5_modify_header_dealloc+0xd/0x70
   rx_create+0x374/0x590
   rx_add_rule+0x3ad/0x500
   ? rx_add_rule+0x3ad/0x500
   ? mlx5_cmd_exec+0x2c/0x40
   ? mlx5_create_ipsec_obj+0xd6/0x200
   mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0
   mlx5e_xfrm_add_state+0x426/0xc00
  <snip>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/16d66a4fa81da07bc4ed19f4e53b87263c2f8d38; https://git.kernel.org/stable/c/b0a15cde37a8388e57573686f650a17208ae1212; https://git.kernel.org/stable/c/cc9ac559f2e21894c21ac5b0c85fb24a5cab266c
CVE: CVE-2024-36286
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()

syzbot reported that nf_reinject() could be called without rcu_read_lock() :

WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
  #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
  #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
  #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172

stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
 <IRQ>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
  rcu_do_batch kernel/rcu/tree.c:2196 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
  __do_softirq kernel/softirq.c:588 [inline]
  invoke_softirq kernel/softirq.c:428 [inline]
  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
 </IRQ>
 <TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a; https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4; https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256
CVE: CVE-2024-36478
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'

Writing 'power' and 'submit_queues' concurrently will trigger kernel
panic:

Test script:

modprobe null_blk nr_devices=0
mkdir -p /sys/kernel/config/nullb/nullb0
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
while true; do echo 1 > power; echo 0 > power; done

Test result:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:__lock_acquire+0x41d/0x28f0
Call Trace:
 <TASK>
 lock_acquire+0x121/0x450
 down_write+0x5f/0x1d0
 simple_recursive_removal+0x12f/0x5c0
 blk_mq_debugfs_unregister_hctxs+0x7c/0x100
 blk_mq_update_nr_hw_queues+0x4a3/0x720
 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
 nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
 configfs_write_iter+0x119/0x1e0
 vfs_write+0x326/0x730
 ksys_write+0x74/0x150

This is because del_gendisk() can concurrent with
blk_mq_update_nr_hw_queues():

nullb_device_power_store	nullb_apply_submit_queues
 null_del_dev
 del_gendisk
				 nullb_update_nr_hw_queues
				  if (!dev->nullb)
				  // still set while gendisk is deleted
				   return 0
				  blk_mq_update_nr_hw_queues
 dev->nullb = NULL

Fix this problem by resuing the global mutex to protect
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1d4c8baef435c98e8d5aa7027dc5a9f70834ba16; https://git.kernel.org/stable/c/5d0495473ee4c1d041b5a917f10446a22c047f47; https://git.kernel.org/stable/c/a2db328b0839312c169eb42746ec46fc1ab53ed2
CVE: CVE-2024-36484
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: relax socket state check at accept time.

Christoph reported the following splat:

WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0
Modules linked in:
CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759
Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80
RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293
RAX: ffffffff836bdd14 RBX: [PII_REDACTED] RCX: ffff[PII_REDACTED]00
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: dffffc[PII_REDACTED] R08: ffffffff836bdb89 R09: fffff52000185f64
R10: dffffc[PII_REDACTED] R11: fffff52000185f64 R12: dffffc[PII_REDACTED]
R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800
FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fb9fcf2e178 CR3:[PII_REDACTED]5d2002 CR4:[PII_REDACTED]770ef0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
PKRU: 55555554
Call Trace:
 <TASK>
 inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786
 do_accept+0x435/0x620 net/socket.c:1929
 __sys_accept4_file net/socket.c:1969 [inline]
 __sys_accept4+0x9b/0x110 net/socket.c:1999
 __do_sys_accept net/socket.c:2016 [inline]
 __se_sys_accept net/socket.c:2013 [inline]
 __x64_sys_accept+0x7d/0x90 net/socket.c:2013
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x4315f9
Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 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 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX:[PII_REDACTED]00002b
RAX: ffffffffffffffda RBX: [PII_REDACTED] RCX:[PII_REDACTED]4315f9
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP:[PII_REDACTED]6e1018 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13:[PII_REDACTED]40cdf0 R14:[PII_REDACTED]40ce80 R15: [PII_REDACTED]
 </TASK>

The reproducer invokes shutdown() before entering the listener status.
After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for
TCP_SYN_RECV sockets"), the above causes the child to reach the accept
syscall in FIN_WAIT1 status.

Eric noted we can relax the existing assertion in __inet_accept()
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/21c14c556cccd0cb54b71ec5e901e64ba84c7165; https://git.kernel.org/stable/c/26afda78cda3da974fd4c287962c169e9462c495; https://git.kernel.org/stable/c/59801e88c99f7c3f44a4d20af6ba6417aa359b5d
CVE: CVE-2024-36489
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

tls: fix missing memory barrier in tls_init

In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

CPU0                               CPU1
-----                              -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)

// In update_sk_prot()
WRITE_ONCE(sk->sk_prot, tls_prots)     -(2)

                                   // In sock_common_setsockopt()
                                   READ_ONCE(sk->sk_prot)->setsockopt()

                                   // In tls_{setsockopt,getsockopt}()
                                   ctx->sk_proto->setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx->sk_proto, causing NULL dereference.

To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is
initialized, we can ensure that ctx->sk_proto are visible when
changing sk->sk_prot.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b; https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b; https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302
CVE: CVE-2024-37353
Published: 2024-06-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-38381
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: Fix uninit-value in nci_rx_work

syzbot reported the following uninit-value access issue [1]

nci_rx_work() parses received packet from ndev->rx_q. It should be
validated header size, payload size and total packet size before
processing the packet. If an invalid packet is detected, it should be
silently discarded.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908
References: https://git.kernel.org/stable/c/017ff397624930fd7ac7f1761f3c9d6a7100f68c; https://git.kernel.org/stable/c/406cfac9debd4a6d3dc5d9258ee086372a8c08b6; https://git.kernel.org/stable/c/485ded868ed62ceb2acb3a459d7843fd71472619
CVE: CVE-2024-38388
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup

Use the control private_free callback to free the associated data
block. This ensures that the memory won't leak, whatever way the
control gets destroyed.

The original implementation didn't actually remove the ALSA
controls in hda_cs_dsp_control_remove(). It only freed the internal
tracking structure. This meant it was possible to remove/unload the
amp driver while leaving its ALSA controls still present in the
soundcard. Obviously attempting to access them could cause segfaults
or at least dereferencing stale pointers.
CVSS Score: 3.3 (LOW)
CWE: CWE-401
References: https://git.kernel.org/stable/c/172811e3a557d8681a5e2d0f871dc04a2d17eb13; https://git.kernel.org/stable/c/191dc1b2ff0fb35e7aff15a[PII_REDACTED]7df8bff; https://git.kernel.org/stable/c/3291486af[PII_REDACTED]ea55bae985f3eaa5b0740
CVE: CVE-2024-38390
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails

Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer
dereference on:

msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);

as gpu->pdev is only assigned in:

a6xx_gpu_init()
|_ adreno_gpu_init
    |_ msm_gpu_init()

Instead of relying on handwavy null checks down the cleanup chain,
explicitly de-allocate the LLC data and free a6xx_gpu instead.

Patchwork: https://patchwork.freedesktop.org/patch/588919/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/247849eeb3fd88f8990ed73e33af70d5c10f9aec; https://git.kernel.org/stable/c/46d4efcccc688cbacdd70a238bedca510acaa8e4; https://git.kernel.org/stable/c/617e3d1680504a3f9d88e1582892c68be155498f
CVE: CVE-2024-38391
Published: 2024-06-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-38621
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: stk1160: fix bounds checking in stk1160_copy_video()

The subtract in this condition is reversed.  The ->length is the length
of the buffer.  The ->bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it's unsigned then the result
is a very high positive value.  That means the overflow check is never
true.

Additionally, the ->bytesused doesn't actually work for this purpose
because we're not writing to "buf->mem + buf->bytesused".  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf->length bytes.
CVSS Score: 7.1 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd; https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca899b9261; https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7
CVE: CVE-2024-38622
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: Add callback function pointer check before its call

In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
but then callback function is unconditionally called by this pointer.
Fix this bug by adding conditional return.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Patchwork: https://patchwork.freedesktop.org/patch/588237/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/530f272053a5e72243a9cb07bb1296af6c346002; https://git.kernel.org/stable/c/873f[PII_REDACTED]2c2a996c4e10faac8ff860c241; https://git.kernel.org/stable/c/9078630ed7f8f25d65d11823e7f2b11a8e2f4f0f
CVE: CVE-2024-38623
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning:
	ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef; https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1; https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7
CVE: CVE-2024-38624
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression:
	vbo = 2 * vbo + skip
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/109d85a98345ee52d47c650405dc51bdd2bc7d40; https://git.kernel.org/stable/c/2d1ad595d15f36a925480199bf1d9ad72614210b; https://git.kernel.org/stable/c/847db4049f6189427ddaefcfc967d4d235b73c57
CVE: CVE-2024-38625
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Check 'folio' pointer for NULL

It can be NULL if bmap is called.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803; https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8; https://git.kernel.org/stable/c/ff[PII_REDACTED]47f9e47f8d14c409dcf938c2641
CVE: CVE-2024-38626
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fuse: clear FR_SENT when re-adding requests into pending list

The following warning was reported by lee bruce:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300
  fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300
  Modules linked in:
  CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300
  ......
  Call Trace:
  <TASK>
  fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334
  fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367
  call_read_iter include/linux/fs.h:2104 [inline]
  new_sync_read fs/read_write.c:395 [inline]
  vfs_read+0x85b/0xba0 fs/read_write.c:476
  ksys_read+0x12f/0x260 fs/read_write.c:619
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ......
  </TASK>

The warning is due to the FUSE_NOTIFY_RESEND notify sent by the write()
syscall in the reproducer program and it happens as follows:

(1) calls fuse_dev_read() to read the INIT request
The read succeeds. During the read, bit FR_SENT will be set on the
request.
(2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify
The resend notify will resend all processing requests, so the INIT
request is moved from processing list to pending list again.
(3) calls fuse_dev_read() with an invalid output address
fuse_dev_read() will try to copy the same INIT request to the output
address, but it will fail due to the invalid address, so the INIT
request is ended and triggers the warning in fuse_request_end().

Fix it by clearing FR_SENT when re-adding requests into pending list.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/246014876d782bbf2e652267482cd2e799fb5fcd; https://git.kernel.org/stable/c/533070db659a9589310a743e9de14cf9d651ffaf; https://git.kernel.org/stable/c/246014876d782bbf2e652267482cd2e799fb5fcd
CVE: CVE-2024-38627
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

stm class: Fix a double free in stm_register_device()

The put_device(&stm->dev) call will trigger stm_device_release() which
frees "stm" so the vfree(stm) on the next line is a double free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20; https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459; https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247
CVE: CVE-2024-38628
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.

Hang on to the control IDs instead of pointers since those are correctly
handled with locks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464; https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0; https://git.kernel.org/stable/c/89e[PII_REDACTED]5590ea0b32c3178e42cba36ac09
CVE: CVE-2024-38629
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Avoid unnecessary destruction of file_ida

file_ida is allocated during cdev open and is freed accordingly
during cdev release. This sequence is guaranteed by driver file
operations. Therefore, there is no need to destroy an already empty
file_ida when the WQ cdev is removed.

Worse, ida_free() in cdev release may happen after destruction of
file_ida per WQ cdev. This can lead to accessing an id in file_ida
after it has been destroyed, resulting in a kernel panic.

Remove ida_destroy(&file_ida) to address these issues.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/15edb906211bf53e7b5574f7326ab734d6bff4f9; https://git.kernel.org/stable/c/76e43fa6a456787bad31b8d0daeabda27351a480; https://git.kernel.org/stable/c/9eb15f24a0b9b017b39cde8b8c07243676b63687
CVE: CVE-2024-38630
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.

Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/[PII_REDACTED]77119f2e2ba5f28ae6e87fc594f4d4; https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314; https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a
CVE: CVE-2024-38631
Published: 2024-06-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: PAC1934: fix accessing out of bounds array index

Fix accessing out of bounds array index for average
current and voltage measurements. The device itself has
only 4 channels, but in sysfs there are "fake"
channels for the average voltages and currents too.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/51fafb3cd7fcf4f4682693b4d2883e2a5bfffe33; https://git.kernel.org/stable/c/8dbcb3a8cfdf8ff5afce62dad50790278ff0d3b7; https://git.kernel.org/stable/c/51fafb3cd7fcf4f4682693b4d2883e2a5bfffe33