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

netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type

Lion Ackermann reported that there is a race condition between namespace cleanup
in ipset and the garbage collection of the list:set type. The namespace
cleanup can destroy the list:set type of sets while the gc of the set type is
waiting to run in rcu cleanup. The latter uses data from the destroyed set which
thus leads use after free. The patch contains the following parts:

- When destroying all sets, first remove the garbage collectors, then wait
  if needed and then destroy the sets.
- Fix the badly ordered "wait then remove gc" for the destroy a single set
  case.
- Fix the missing rcu locking in the list:set type in the userspace test
  case.
- Use proper RCU list handlings in the list:set type.

The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/0f1bb77c6d837c9513943bc7c08f04c5cc5c6568; https://git.kernel.org/stable/c/2ba35b37f780c6410bb4bba9c3072596d8576702; https://git.kernel.org/stable/c/390b353d1a1da3e9c6c0fd14fe650d69063c95d6
CVE: CVE-2024-39504
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_inner: validate mandatory meta and payload

Check for mandatory netlink attributes in payload and meta expression
when used embedded from the inner expression, otherwise NULL pointer
dereference is possible from userspace.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/39323f54cad[PII_REDACTED]8346c71b087da92a19d; https://git.kernel.org/stable/c/b30669fdea0ca03aa22995e6c99f7e7d9dee89ff; https://git.kernel.org/stable/c/c4ab9da85b9df3692f861512fe6c9812f38b7471
CVE: CVE-2024-39505
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/komeda: check for error-valued pointer

komeda_pipeline_get_state() may return an error-valued pointer, thus
check the pointer for negative or null value before dereferencing.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0674ed1e58e2fdcc155e7d944f8aad007a94ac69; https://git.kernel.org/stable/c/3b1cf943b029c147bfacfd53dc28ffa632c0a622; https://git.kernel.org/stable/c/86042e3d16b7e0686db835c9e7af0f9044dd3a56
CVE: CVE-2024-39506
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet

In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
but then it is unconditionally passed to skb_add_rx_frag() which looks
strange and could lead to null pointer dereference.

lio_vf_rep_copy_packet() call trace looks like:
	octeon_droq_process_packets
	 octeon_droq_fast_process_packets
	  octeon_droq_dispatch_pkt
	   octeon_create_recv_info
	    ...search in the dispatch_list...
	     ->disp_fn(rdisp->rinfo, ...)
	      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
In this path there is no code which sets pg_info->page to NULL.
So this check looks unneeded and doesn't solve potential problem.
But I guess the author had reason to add a check and I have no such card
and can't do real test.
In addition, the code in the function liquidio_push_packet() in
liquidio/lio_core.c does exactly the same.

Based on this, I consider the most acceptable compromise solution to
adjust this issue by moving skb_add_rx_frag() into conditional scope.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2; https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa; https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c
CVE: CVE-2024-39507
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash problem in concurrent scenario

When link status change, the nic driver need to notify the roce
driver to handle this event, but at this time, the roce driver
may uninit, then cause kernel crash.

To fix the problem, when link status change, need to check
whether the roce registered, and when uninit, need to wait link
update finish.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4; https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf[PII_REDACTED]495f9ee48; https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa
CVE: CVE-2024-39508
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/io-wq: Use set_bit() and test_bit() at worker->flags

Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
to address potential data races.

The structure io_worker->flags may be accessed through various data
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
data races occurring in io_worker_handle_work and
io_wq_activate_free_worker functions.

	 BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
	 write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
	 io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
	 io_wq_worker (io_uring/io-wq.c:?)
<snip>

	 read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
	 io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
	 io_wq_enqueue (io_uring/io-wq.c:947)
	 io_queue_iowq (io_uring/io_uring.c:524)
	 io_req_task_submit (io_uring/io_uring.c:1511)
	 io_handle_tw_list (io_uring/io_uring.c:1198)
<snip>

Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm").

These races involve writes and reads to the same memory location by
different tasks running on different CPUs. To mitigate this, refactor
the code to use atomic operations such as set_bit(), test_bit(), and
clear_bit() instead of basic "and" and "or" operations. This ensures
thread-safe manipulation of worker flags.

Also, move `create_index` to avoid holes in the structure.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1cbb0affb15470a9621267fe0a[PII_REDACTED]a4bf; https://git.kernel.org/stable/c/8a565304927fbd28c9f028c492b5c1714002cbab; https://git.kernel.org/stable/c/ab702c3483db9046bab9f40306f1a28b22dbbdc0
CVE: CVE-2024-39509
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: core: remove unnecessary WARN_ON() in implement()

Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.

Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
	...
	value &= m;
	...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.

[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
 <TASK>
 __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
 usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:904 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
 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)
CWE: CWE-617
References: https://git.kernel.org/stable/c/30f76bc468b9b2cbbd5d3eb482661e3e4798893f; https://git.kernel.org/stable/c/33f6832798dd[PII_REDACTED]cc1db556ac3ae80c24; https://git.kernel.org/stable/c/4aa2dcfbad538adf7becd0034a3754e1bd01b2b5
CVE: CVE-2024-39510
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read()

We got the following issue in a fuzz test of randomly issuing the restore
command:

==================================================================
BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0xb41/0xb60
Read of size 8 at addr ffff888122e84088 by task ondemand-04-dae/963

CPU: 13 PID: 963 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #564
Call Trace:
 kasan_report+0x93/0xc0
 cachefiles_ondemand_daemon_read+0xb41/0xb60
 vfs_read+0x169/0xb50
 ksys_read+0xf5/0x1e0

Allocated by task 116:
 kmem_cache_alloc+0x140/0x3a0
 cachefiles_lookup_cookie+0x140/0xcd0
 fscache_cookie_state_machine+0x43c/0x1230
 [...]

Freed by task 792:
 kmem_cache_free+0xfe/0x390
 cachefiles_put_object+0x241/0x480
 fscache_cookie_state_machine+0x5c8/0x1230
 [...]
==================================================================

Following is the process that triggers the issue:

     mount  |   daemon_thread1    |    daemon_thread2
------------------------------------------------------------
cachefiles_withdraw_cookie
 cachefiles_ondemand_clean_object(object)
  cachefiles_ondemand_send_req
   REQ_A = kzalloc(sizeof(*req) + data_len)
   wait_for_completion(&REQ_A->done)

            cachefiles_daemon_read
             cachefiles_ondemand_daemon_read
              REQ_A = cachefiles_ondemand_select_req
              msg->object_id = req->object->ondemand->ondemand_id
                                  ------ restore ------
                                  cachefiles_ondemand_restore
                                  xas_for_each(&xas, req, ULONG_MAX)
                                   xas_set_mark(&xas, CACHEFILES_REQ_NEW)

                                  cachefiles_daemon_read
                                   cachefiles_ondemand_daemon_read
                                    REQ_A = cachefiles_ondemand_select_req
              copy_to_user(_buffer, msg, n)
               xa_erase(&cache->reqs, id)
               complete(&REQ_A->done)
              ------ close(fd) ------
              cachefiles_ondemand_fd_release
               cachefiles_put_object
 cachefiles_put_object
  kmem_cache_free(cachefiles_object_jar, object)
                                    REQ_A->object->ondemand->ondemand_id
                                     // object UAF !!!

When we see the request within xa_lock, req->object must not have been
freed yet, so grab the reference count of object before xa_unlock to
avoid the above issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3958679c[PII_REDACTED]9b32be[PII_REDACTED]a51abd; https://git.kernel.org/stable/c/93064676a2820420a2d37d7c8289f277fe20793d; https://git.kernel.org/stable/c/cb55625f8eb9d2de8be4da0c4580d48cbb32058e
CVE: CVE-2024-40900
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: remove requests from xarray during flushing requests

Even with CACHEFILES_DEAD set, we can still read the requests, so in the
following concurrency the request may be used after it has been freed:

     mount  |   daemon_thread1    |    daemon_thread2
------------------------------------------------------------
 cachefiles_ondemand_init_object
  cachefiles_ondemand_send_req
   REQ_A = kzalloc(sizeof(*req) + data_len)
   wait_for_completion(&REQ_A->done)
            cachefiles_daemon_read
             cachefiles_ondemand_daemon_read
                                  // close dev fd
                                  cachefiles_flush_reqs
                                   complete(&REQ_A->done)
   kfree(REQ_A)
              xa_lock(&cache->reqs);
              cachefiles_ondemand_select_req
                req->msg.opcode != CACHEFILES_OP_READ
                // req use-after-free !!!
              xa_unlock(&cache->reqs);
                                   xa_destroy(&cache->reqs)

Hence remove requests from cache->reqs when flushing them to avoid
accessing freed requests.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0fc75c5940fa634d84e64c93bfc388e1274ed013; https://git.kernel.org/stable/c/37e19cf86a520d65de1de9cb330415c332a40d19; https://git.kernel.org/stable/c/50d0e55356ba5b84ffb51c[PII_REDACTED]4257e598
CVE: CVE-2024-40901
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory

There is a potential out-of-bounds access when using test_bit() on a single
word. The test_bit() and set_bit() functions operate on long values, and
when testing or setting a single word, they can exceed the word
boundary. KASAN detects this issue and produces a dump:

	 BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas

	 Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965

For full log, please look at [1].

Make the allocation at least the size of sizeof(unsigned long) so that
set_bit() and test_bit() have sufficient room for read/write operations
without overwriting unallocated memory.

[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0081d2b3ae0a17a86b8cc0fa3c8bdc54e233ba16; https://git.kernel.org/stable/c/18abb5db0aa9b2d48f7037a88b41af2eef821674; https://git.kernel.org/stable/c/19649e49a6df07cd2e03e0a11396fd3a99485ec2
CVE: CVE-2024-40902
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: xattr: fix buffer overflow for invalid xattr

When an xattr size is not what is expected, it is printed out to the
kernel log in hex format as a form of debugging.  But when that xattr
size is bigger than the expected size, printing it out can cause an
access off the end of the buffer.

Fix this all up by properly restricting the size of the debug hex dump
in the kernel log.
CVSS Score: 7.8 (HIGH)
CWE: CWE-120, CWE-121
References: https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a; https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123; https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69
CVE: CVE-2024-40903
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps

There could be a potential use-after-free case in
tcpm_register_source_caps(). This could happen when:
 * new (say invalid) source caps are advertised
 * the existing source caps are unregistered
 * tcpm_register_source_caps() returns with an error as
   usb_power_delivery_register_capabilities() fails

This causes port->partner_source_caps to hold on to the now freed source
caps.

Reset port->partner_source_caps value to NULL after unregistering
existing source caps.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/04c05d50fa79a41582f7bde8a1fd4377ae4a39e5; https://git.kernel.org/stable/c/[PII_REDACTED]d7235f3638d49a00cf0f289e4b36a3; https://git.kernel.org/stable/c/6b67b652849faf108a09647c7fde9b179ef24e2b
CVE: CVE-2024-40904
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages

The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:

cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
	#1:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#2:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#3:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#4:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#5:  98% system,	  1% softirq,	  3% hardirq,	  0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last  enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last  enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last  enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last  enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024

Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.

In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls.  Therefore we replace them with
dev_err_ratelimited().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94; https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28; https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56
CVE: CVE-2024-40907
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ionic: fix kernel panic in XDP_TX action

In the XDP_TX path, ionic driver sends a packet to the TX path with rx
page and corresponding dma address.
After tx is done, ionic_tx_clean() frees that page.
But RX ring buffer isn't reset to NULL.
So, it uses a freed page, which causes kernel panic.

BUG: unable to handle page fault for address: ffff8881576c110c
PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060
Oops: Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
RIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f
Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8
RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283
RAX: [PII_REDACTED] RBX: ffff8881576c1140 RCX: [PII_REDACTED]
RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e
RBP: ffff888104e6fa88 R08: [PII_REDACTED] R09: ffffed1027a04a23
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff8881b03a21a8
R13: ffff8881589f800f R14: ffff8881576c1100 R15:[PII_REDACTED]6c1100
FS: [PII_REDACTED](0000) GS:ffff88881ae00000(0000) knlGS:[PII_REDACTED]
CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: ffff8881576c110c CR3:[PII_REDACTED]a90000 CR4:[PII_REDACTED]7506f0
PKRU: 55555554
Call Trace:
<TASK>
? __die+0x20/0x70
? page_fault_oops+0x254/0x790
? __pfx_page_fault_oops+0x10/0x10
? __pfx_is_prefetch.constprop.0+0x10/0x10
? search_bpf_extables+0x165/0x260
? fixup_exception+0x4a/0x970
? exc_page_fault+0xcb/0xe0
? asm_exc_page_fault+0x22/0x30
? 0xffffffffc0051f64
? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f
? do_raw_spin_unlock+0x54/0x220
ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
? ionic_tx_clean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
ionic_txrx_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]
__napi_poll.constprop.0+0xa0/0x440
net_rx_action+0x7e7/0xc30
? __pfx_net_rx_action+0x10/0x10
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/491aee894a08bc9b8bb52e7363b9d4bc6403f363; https://git.kernel.org/stable/c/8812aa35f3e930f61074b9c1ecea26f354992c21; https://git.kernel.org/stable/c/491aee894a08bc9b8bb52e7363b9d4bc6403f363
CVE: CVE-2024-40908
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Set run context for rawtp test_run callback

syzbot reported crash when rawtp program executed through the
test_run interface calls bpf_get_attach_cookie helper or any
other helper that touches task->bpf_ctx pointer.

Setting the run context (task->bpf_ctx pointer) for test_run
callback.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3708b6c2546c9eb34aead8a34a17e8ae69004e4d; https://git.kernel.org/stable/c/789bd77c9342aa[PII_REDACTED]ae5c6034d0f6f9d2; https://git.kernel.org/stable/c/ae0ba0ab7475a129ef7d449966edf677367efeb4
CVE: CVE-2024-40909
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a potential use-after-free in bpf_link_free()

After commit 1a80dbcb2dba, bpf_link can be freed by
link->ops->dealloc_deferred, but the code still tests and uses
link->ops->dealloc afterward, which leads to a use-after-free as
reported by syzbot. Actually, one of them should be sufficient, so
just call one of them instead of both. Also add a WARN_ON() in case
of any problematic implementation.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2884dc7d08d98a89d8d65121524bb7533183a63a; https://git.kernel.org/stable/c/91cff53136daeff50816b0baeafd38a6976f6209; https://git.kernel.org/stable/c/fa97b8fed9896f1e89cb657513e483a152d4c382