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

cxl/port: Fix delete_endpoint() vs parent unregistration race

The CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of
ports (struct cxl_port objects) between an endpoint and the root of a
CXL topology. Each port including the endpoint port is attached to the
cxl_port driver.

Given that setup, it follows that when either any port in that lineage
goes through a cxl_port ->remove() event, or the memdev goes through a
cxl_mem ->remove() event. The hierarchy below the removed port, or the
entire hierarchy if the memdev is removed needs to come down.

The delete_endpoint() callback is careful to check whether it is being
called to tear down the hierarchy, or if it is only being called to
teardown the memdev because an ancestor port is going through
->remove().

That care needs to take the device_lock() of the endpoint's parent.
Which requires 2 bugs to be fixed:

1/ A reference on the parent is needed to prevent use-after-free
   scenarios like this signature:

    BUG: spinlock bad magic on CPU#0, kworker/u56:0/11
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023
    Workqueue: cxl_port detach_memdev [cxl_core]
    RIP: 0010:spin_bug+0x65/0xa0
    Call Trace:
      do_raw_spin_lock+0x69/0xa0
     __mutex_lock+0x695/0xb80
     delete_endpoint+0xad/0x150 [cxl_core]
     devres_release_all+0xb8/0x110
     device_unbind_cleanup+0xe/0x70
     device_release_driver_internal+0x1d2/0x210
     detach_memdev+0x15/0x20 [cxl_core]
     process_one_work+0x1e3/0x4c0
     worker_thread+0x1dd/0x3d0

2/ In the case of RCH topologies, the parent device that needs to be
   locked is not always @port->dev as returned by cxl_mem_find_port(), use
   endpoint->dev.parent instead.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/37179fcc916bce8c3cc7b36d67ef814cce55142b; https://git.kernel.org/stable/c/6b2e428e673b3f55965674a426c40922e91388aa; https://git.kernel.org/stable/c/8d2ad999ca3c64cb08cf6a58d227b9d9e746d708
CVE: CVE-2023-52773
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer()

When ddc_service_construct() is called, it explicitly checks both the
link type and whether there is something on the link which will
dictate whether the pin is marked as hw_supported.

If the pin isn't set or the link is not set (such as from
unloading/reloading amdgpu in an IGT test) then fail the
amdgpu_dm_i2c_xfer() call.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1d07b7e84276777dad3c8cfebdf8e739606f90c9; https://git.kernel.org/stable/c/5b14cf37b9f01de0b28c6f8960019d4c7883ce42; https://git.kernel.org/stable/c/b71f4ade1b8900d30c661d6c27f87c35214c398c
CVE: CVE-2023-52774
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: protect device queue against concurrent access

In dasd_profile_start() the amount of requests on the device queue are
counted. The access to the device queue is unprotected against
concurrent access. With a lot of parallel I/O, especially with alias
devices enabled, the device queue can change while dasd_profile_start()
is accessing the queue. In the worst case this leads to a kernel panic
due to incorrect pointer accesses.

Fix this by taking the device lock before accessing the queue and
counting the requests. Additionally the check for a valid profile data
pointer can be done earlier to avoid unnecessary locking in a hot path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6062c527d0403cef27c54b91ac8390c3a497b250; https://git.kernel.org/stable/c/9372aab5d0ff621ea203c8c603e7e5f75e888240; https://git.kernel.org/stable/c/c841de6247e94e07566d57163d3c0d8b29278f7a
CVE: CVE-2023-52775
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: avoid data corruption caused by decline

We found a data corruption issue during testing of SMC-R on Redis
applications.

The benchmark has a low probability of reporting a strange error as
shown below.

"Error: Protocol error, got "\xe2" as reply type byte"

Finally, we found that the retrieved error data was as follows:

0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C
0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2

It is quite obvious that this is a SMC DECLINE message, which means that
the applications received SMC protocol message.
We found that this was caused by the following situations:

client                  server
        ¦  clc proposal
        ------------->
        ¦  clc accept
        <-------------
        ¦  clc confirm
        ------------->
wait llc confirm
			send llc confirm
        ¦failed llc confirm
        ¦   x------
(after 2s)timeout
                        wait llc confirm rsp

wait decline

(after 1s) timeout
                        (after 2s) timeout
        ¦   decline
        -------------->
        ¦   decline
        <--------------

As a result, a decline message was sent in the implementation, and this
message was read from TCP by the already-fallback connection.

This patch double the client timeout as 2x of the server value,
With this simple change, the Decline messages should never cross or
collide (during Confirm link timeout).

This issue requires an immediate solution, since the protocol updates
involve a more long-term solution.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/5ada292b5c504720a0acef8cae9acc62a694d19c; https://git.kernel.org/stable/c/7234d2b5dffa5af77fd4e0deaebab509e130c6b1; https://git.kernel.org/stable/c/90072af9efe8c7bd7d086709014ddd44cebd5e7c
CVE: CVE-2023-52776
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix dfs-radar and temperature event locking

The ath12k active pdevs are protected by RCU but the DFS-radar and
temperature event handling code calling ath12k_mac_get_ar_by_pdev_id()
was not marked as a read-side critical section.

Mark the code in question as RCU read-side critical sections to avoid
any potential use-after-free issues.

Note that the temperature event handler looks like a place holder
currently but would still trigger an RCU lockdep splat.

Compile tested only.
CVSS Score: 5.9 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/69bd216e[PII_REDACTED]05b1c87a55dce3d35d1ba7; https://git.kernel.org/stable/c/774de37c147fea81f2c2e4be5082304f4f71d535; https://git.kernel.org/stable/c/d7a5f7f76568e48869916d769e28b9f3ca70c78e
CVE: CVE-2023-52777
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix gtk offload status event locking

The ath11k active pdevs are protected by RCU but the gtk offload status
event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not
marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.

Compile tested only.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0cf7577b6b3153b4b49deea9719fe43f96469c6d; https://git.kernel.org/stable/c/1dea3c0720a146bd7193969f2847ccfed5be2221; https://git.kernel.org/stable/c/cf9c7d783a2bf9305df4ef5b93d9063a52e18fca
CVE: CVE-2023-52778
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: deal with large GSO size

After the blamed commit below, the TCP sockets (and the MPTCP subflows)
can build egress packets larger than 64K. That exceeds the maximum DSS
data size, the length being misrepresent on the wire and the stream being
corrupted, as later observed on the receiver:

  WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0
  CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
  RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705
  RSP: 0018:ffffc90000006e80 EFLAGS: 00010246
  RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000
  netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
  RBP: ffffc[PII_REDACTED]0 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a
  R10: dffffc[PII_REDACTED] R11: ffffed100e548c8b R12: [PII_REDACTED]
  R13: dffffc[PII_REDACTED] R14: [PII_REDACTED] R15:[PII_REDACTED]31cf29
  FS:  00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 00007f239c45cd78 CR3: 000000006a66c006 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:
   <IRQ>
   mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819
   subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409
   tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151
   tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098
   tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483
   tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749
   ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438
   ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483
   ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304
   __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532
   process_backlog+0x353/0x660 net/core/dev.c:5974
   __napi_poll+0xc6/0x5a0 net/core/dev.c:6536
   net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603
   __do_softirq+0x184/0x524 kernel/softirq.c:553
   do_softirq+0xdd/0x130 kernel/softirq.c:454

Address the issue explicitly bounding the maximum GSO size to what MPTCP
actually allows.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/342b528c0e849bed9def76dadaa470d3af678e94; https://git.kernel.org/stable/c/57ced2eb77343a91d28f4a73675b05fe7b555def; https://git.kernel.org/stable/c/70ff9b65a72885b3a2dfde6709da1f19b85fa696
CVE: CVE-2023-52779
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: Pass AT_GETATTR_NOSEC flag to getattr interface function

When vfs_getattr_nosec() calls a filesystem's getattr interface function
then the 'nosec' should propagate into this function so that
vfs_getattr_nosec() can again be called from the filesystem's gettattr
rather than vfs_getattr(). The latter would add unnecessary security
checks that the initial vfs_getattr_nosec() call wanted to avoid.
Therefore, introduce the getattr flag GETATTR_NOSEC and allow to pass
with the new getattr_flags parameter to the getattr interface function.
In overlayfs and ecryptfs use this flag to determine which one of the
two functions to call.

In a recent code change introduced to IMA vfs_getattr_nosec() ended up
calling vfs_getattr() in overlayfs, which in turn called
security_inode_getattr() on an exiting process that did not have
current->fs set anymore, which then caused a kernel NULL pointer
dereference. With this change the call to security_inode_getattr() can
be avoided, thus avoiding the NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3fb0fa[PII_REDACTED]4b9d81d52a379ff031dc41d4; https://git.kernel.org/stable/c/8a924db2d7b5eb69ba08b1a0af46e9f1359a9bdf; https://git.kernel.org/stable/c/3fb0fa[PII_REDACTED]4b9d81d52a379ff031dc41d4
CVE: CVE-2023-52781
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: config: fix iteration issue in 'usb_get_bos_descriptor()'

The BOS descriptor defines a root descriptor and is the base descriptor for
accessing a family of related descriptors.

Function 'usb_get_bos_descriptor()' encounters an iteration issue when
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
the same descriptor being read repeatedly.

To address this issue, a 'goto' statement is introduced to ensure that the
pointer and the amount read is updated correctly. This ensures that the
function iterates to the next descriptor instead of reading the same
descriptor repeatedly.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-670
References: https://git.kernel.org/stable/c/64c27b7b2357ddb38b6afebaf46d5bff4d250702; https://git.kernel.org/stable/c/7c0244cc311a4038505b73682b7c8ceaa5c7a8c8; https://git.kernel.org/stable/c/974bba5c118f4c2baf00de0356e3e4f7928b4cbc
CVE: CVE-2023-52783
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: wangxun: fix kernel panic due to null pointer

When the device uses a custom subsystem vendor ID, the function
wx_sw_init() returns before the memory of 'wx->mac_table' is allocated.
The null pointer will causes the kernel panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/61a[PII_REDACTED]4dab172d4c5d699bb365cfd13c9; https://git.kernel.org/stable/c/8ba2c459668cfe2aaacc5ebcd35b4b9ef8643013; https://git.kernel.org/stable/c/61a[PII_REDACTED]4dab172d4c5d699bb365cfd13c9
CVE: CVE-2023-52785
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR

If command timeout happens and cq complete IRQ is raised at the same time,
ufshcd_mcq_abort clears lprb->cmd and a NULL pointer deref happens in the
ISR. Error log:

ufshcd_abort: Device abort task at tag 18
Unable to handle kernel NULL pointer dereference at virtual address
[PII_REDACTED]
pc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44
lr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/27900d7119c464b43cd9eac69c85884d17bae240; https://git.kernel.org/stable/c/8f15a7e3c054d960bbd[PII_REDACTED]50bbf798a1; https://git.kernel.org/stable/c/f84d461f33a6b27304d468d9cfb56c0cefdb4ee7
CVE: CVE-2023-52786
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix racy may inline data check in dio write

syzbot reports that the following warning from ext4_iomap_begin()
triggers as of the commit referenced below:

        if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
                return -ERANGE;

This occurs during a dio write, which is never expected to encounter
an inode with inline data. To enforce this behavior,
ext4_dio_write_iter() checks the current inline state of the inode
and clears the MAY_INLINE_DATA state flag to either fall back to
buffered writes, or enforce that any other writers in progress on
the inode are not allowed to create inline data.

The problem is that the check for existing inline data and the state
flag can span a lock cycle. For example, if the ilock is originally
locked shared and subsequently upgraded to exclusive, another writer
may have reacquired the lock and created inline data before the dio
write task acquires the lock and proceeds.

The commit referenced below loosens the lock requirements to allow
some forms of unaligned dio writes to occur under shared lock, but
AFAICT the inline data check was technically already racy for any
dio write that would have involved a lock cycle. Regardless, lift
clearing of the state bit to the same lock critical section that
checks for preexisting inline data on the inode to close the race.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d; https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808; https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc
CVE: CVE-2023-52787
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: make sure active queue usage is held for bio_integrity_prep()

blk_integrity_unregister() can come if queue usage counter isn't held
for one bio with integrity prepared, so this request may be completed with
calling profile->complete_fn, then kernel panic.

Another constraint is that bio_integrity_prep() needs to be called
before bio merge.

Fix the issue by:

- call bio_integrity_prep() with one queue usage counter grabbed reliably

- call bio_integrity_prep() before bio merge
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab; https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9; https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf
CVE: CVE-2023-52788
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

i915/perf: Fix NULL deref bugs with drm_dbg() calls

When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.

As returning -ENOTSUPP is pretty clear return when perf interface is not
available.

[tursulin: added stable tag]
(cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/10f49cdfd5fb342a1a9641930dc040c570694e98; https://git.kernel.org/stable/c/1566e8be73fd5fa424e88d2a4cffdc34f970f0e1; https://git.kernel.org/stable/c/471aa951bf1206d3c10d0daa67005b8e4db4ff83
CVE: CVE-2023-52789
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: vcc: Add check for kstrdup() in vcc_probe()

Add check for the return value of kstrdup() and return the error, if it
fails in order to avoid NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3; https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac; https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9
CVE: CVE-2023-52790
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

swiotlb: fix out-of-bounds TLB allocations with CONFIG_SWIOTLB_DYNAMIC

Limit the free list length to the size of the IO TLB. Transient pool can be
smaller than IO_TLB_SEGSIZE, but the free list is initialized with the
assumption that the total number of slots is a multiple of IO_TLB_SEGSIZE.
As a result, swiotlb_area_find_slots() may allocate slots past the end of
a transient IO TLB buffer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/53c87e846e335e3c18044c397cc35178163d7827; https://git.kernel.org/stable/c/ce7612496a4ba6068bc68aa1fa9d947dadb4ad9b; https://git.kernel.org/stable/c/53c87e846e335e3c18044c397cc35178163d7827
CVE: CVE-2023-52791
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

i2c: core: Run atomic i2c xfer when !preemptible

Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
disabled. However, non-atomic i2c transfers require preemption (e.g. in
wait_for_completion() while waiting for the DMA).

panic() calls preempt_disable_notrace() before calling
emergency_restart(). Therefore, if an i2c device is used for the
restart, the xfer should be atomic. This avoids warnings like:

[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
[   12.676926] Voluntary context switch within RCU read-side critical section!
...
[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114
[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
...
[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58
[   13.001050]  machine_restart from panic+0x2a8/0x32c

Use !preemptible() instead, which is basically the same check as
pre-v5.2.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/185f3617adc8fe45e40489b458f03911f0dec46c; https://git.kernel.org/stable/c/25284c46b657f48c0f3880a2e0706c70d81182c0; https://git.kernel.org/stable/c/25eb381a736e7ae39a4245ef5c96484eb1073809
CVE: CVE-2023-52792
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/region: Do not try to cleanup after cxl_region_setup_targets() fails

Commit 5e42bcbc3fef ("cxl/region: decrement ->nr_targets on error in
cxl_region_attach()") tried to avoid 'eiw' initialization errors when
->nr_targets exceeded 16, by just decrementing ->nr_targets when
cxl_region_setup_targets() failed.

Commit 86987c766276 ("cxl/region: Cleanup target list on attach error")
extended that cleanup to also clear cxled->pos and p->targets[pos]. The
initialization error was incidentally fixed separately by:
Commit 8d[PII_REDACTED] ("cxl/region: Fix port setup uninitialized variable
warnings") which was merged a few days after 5e42bcbc3fef.

But now the original cleanup when cxl_region_setup_targets() fails
prevents endpoint and switch decoder resources from being reused:

1) the cleanup does not set the decoder's region to NULL, which results
   in future dpa_size_store() calls returning -EBUSY
2) the decoder is not properly freed, which results in future commit
   errors associated with the upstream switch

Now that the initialization errors were fixed separately, the proper
cleanup for this case is to just return immediately. Then the resources
associated with this target get cleanup up as normal when the failed
region is deleted.

The ->nr_targets decrement in the error case also helped prevent
a p->targets[] array overflow, so add a new check to prevent against
that overflow.

Tested by trying to create an invalid region for a 2 switch * 2 endpoint
topology, and then following up with creating a valid region.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0718588c7aaa7a1510b4de972370535b61dddd0d; https://git.kernel.org/stable/c/07ffcd8ec79cf7383e1e45815f4842fd357991c2; https://git.kernel.org/stable/c/9090c5537c93cd0811ab7bfbd925b57addfffb60
CVE: CVE-2023-52793
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-52794
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: intel: powerclamp: fix mismatch in get function for max_idle

KASAN reported this

      [ 444.853098] BUG: KASAN: global-out-of-bounds in param_get_int+0x77/0x90
      [ 444.853111] Read of size 4 at addr ffffffffc16c9220 by task cat/2105
      ...
      [ 444.853442] The buggy address belongs to the variable:
      [ 444.853443] max_idle+0x0/0xffffffffffffcde0 [intel_powerclamp]

There is a mismatch between the param_get_int and the definition of
max_idle.  Replacing param_get_int with param_get_byte resolves this
issue.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0a8585281b11e3a0723bba8d8085d61f0b55f37c; https://git.kernel.org/stable/c/6a3866dbdcf39ac93e98708e6abced511733dc18; https://git.kernel.org/stable/c/fae633cfb729da2771b5433f6b84ae7e8b4aa5f7
CVE: CVE-2023-52795
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost-vdpa: fix use after free in vhost_vdpa_probe()

The put_device() calls vhost_vdpa_release_dev() which calls
ida_simple_remove() and frees "v".  So this call to
ida_simple_remove() is a use after free and a double free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-416
References: https://git.kernel.org/stable/c/ae8ea4e200675a940c365b496ef8e3fb4123601c; https://git.kernel.org/stable/c/bf04132cd64ccde4e9e9765d489c83fe83c09b7f; https://git.kernel.org/stable/c/c0f8b8fb7df9d1a38652eb5aa817afccd3c56111