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

platform/x86: x86-android-tablets: Unregister devices in reverse order

Not all subsystems support a device getting removed while there are
still consumers of the device with a reference to the device.

One example of this is the regulator subsystem. If a regulator gets
unregistered while there are still drivers holding a reference
a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:

 WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister
 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00[PII_REDACTED] FFD8_X64_R_2015_04_10_1516 04/10/2015
 RIP: 0010:regulator_unregister
 Call Trace:
  <TASK>
  regulator_unregister
  devres_release_group
  i2c_device_remove
  device_release_driver_internal
  bus_remove_device
  device_del
  device_unregister
  x86_android_tablet_remove

On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides
a 5V boost converter output for powering USB devices connected to the micro
USB port, the bq24190-charger driver exports this as a Vbus regulator.

On the 830 (8") and 1050 ("10") models this regulator is controlled by
a platform_device and x86_android_tablet_remove() removes platform_device-s
before i2c_clients so the consumer gets removed first.

But on the 1380 (13") model there is a lc824206xa micro-USB switch
connected over I2C and the extcon driver for that controls the regulator.
The bq24190 i2c-client *must* be registered first, because that creates
the regulator with the lc824206xa listed as its consumer. If the regulator
has not been registered yet the lc824206xa driver will end up getting
a dummy regulator.

Since in this case both the regulator provider and consumer are I2C
devices, the only way to ensure that the consumer is unregistered first
is to unregister the I2C devices in reverse order of in which they were
created.

For consistency and to avoid similar problems in the future change
x86_android_tablet_remove() to unregister all device types in reverse
order.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/36ff963c133a25ed1166a25c3ba8b357ea010fda; https://git.kernel.org/stable/c/3de0f2627ef849735f155c1818247f58404dddfe; https://git.kernel.org/stable/c/f0c982853d665597d17e4995ff479fbbf79a9cf6
CVE: CVE-2024-40976
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/lima: mask irqs in timeout path before hard reset

There is a race condition in which a rendering job might take just long
enough to trigger the drm sched job timeout handler but also still
complete before the hard reset is done by the timeout handler.
This runs into race conditions not expected by the timeout handler.
In some very specific cases it currently may result in a refcount
imbalance on lima_pm_idle, with a stack dump such as:

[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
...
[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
...
[10136.669628] Call trace:
[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0
[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0
[10136.669656]  lima_gp_irq_handler+0xa8/0x120
[10136.669666]  __handle_irq_event_percpu+0x48/0x160
[10136.669679]  handle_irq_event+0x4c/0xc0

We can prevent that race condition entirely by masking the irqs at the
beginning of the timeout handler, at which point we give up on waiting
for that job entirely.
The irqs will be enabled again at the next hard reset which is already
done as a recovery by the timeout handler.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/03e7b2f7ae4c0ae5fb8e4e2454ba4008877f196a; https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db; https://git.kernel.org/stable/c/70aa1f2dec46b6fdb5f6b9f37b6bfa4a4dee0d3a
CVE: CVE-2024-40977
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921s: fix potential hung tasks during chip recovery

During chip recovery (e.g. chip reset), there is a possible situation that
kernel worker reset_work is holding the lock and waiting for kernel thread
stat_worker to be parked, while stat_worker is waiting for the release of
the same lock.
It causes a deadlock resulting in the dumping of hung tasks messages and
possible rebooting of the device.

This patch prevents the execution of stat_worker during the chip recovery.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08; https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02; https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9
CVE: CVE-2024-40978
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qedi: Fix crash while reading debugfs attribute

The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.

BUG: unable to handle page fault for address: 00007f[PII_REDACTED]
PGD[PII_REDACTED]df6067 P4D[PII_REDACTED]df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f[PII_REDACTED] RBX: 00007f[PII_REDACTED] RCX:[PII_REDACTED]00000f
RDX:[PII_REDACTED]00000f RSI: ffffffffc0bfd7a0 RDI: 00007f[PII_REDACTED]
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: [PII_REDACTED] R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f[PII_REDACTED] CR3:[PII_REDACTED]b8e001 CR4:[PII_REDACTED]7706e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
PKRU: 55555554
Call Trace:
 <TASK>
 ? __die_body+0x1a/0x60
 ? page_fault_oops+0x183/0x510
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? memcpy_orig+0xcd/0x130
 vsnprintf+0x102/0x4c0
 sprintf+0x51/0x80
 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
 full_proxy_read+0x50/0x80
 vfs_read+0xa5/0x2e0
 ? folio_add_new_anon_rmap+0x44/0xa0
 ? set_pte_at+0x15/0x30
 ? do_pte_missing+0x426/0x7f0
 ksys_read+0xa5/0xe0
 do_syscall_64+0x58/0x80
 ? __count_memcg_events+0x46/0x90
 ? count_memcg_event_mm+0x3d/0x60
 ? handle_mm_fault+0x196/0x2f0
 ? do_user_addr_fault+0x267/0x890
 ? exc_page_fault+0x69/0x150
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4800f20b4d
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/144d76a676b630e[PII_REDACTED]11b00e2de0b40a7; https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901; https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5
CVE: CVE-2024-40980
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drop_monitor: replace spin_lock by raw_spin_lock

trace_drop_common() is called with preemption disabled, and it acquires
a spin_lock. This is problematic for RT kernels because spin_locks are
sleeping locks in this configuration, which causes the following splat:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
5 locks held by rcuc/47/449:
 #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909
hardirqs last  enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
softirqs last  enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
Preemption disabled at:
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
Call Trace:
 <TASK>
 dump_stack_lvl+0x8c/0xd0
 dump_stack+0x14/0x20
 __might_resched+0x21e/0x2f0
 rt_spin_lock+0x5e/0x130
 ? trace_drop_common.constprop.0+0xb5/0x290
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_drop_common.constprop.0+0xb5/0x290
 ? preempt_count_sub+0x1c/0xd0
 ? _raw_spin_unlock_irqrestore+0x4a/0x80
 ? __pfx_trace_drop_common.constprop.0+0x10/0x10
 ? rt_mutex_slowunlock+0x26a/0x2e0
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_rt_mutex_slowunlock+0x10/0x10
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_kfree_skb_hit+0x15/0x20
 trace_kfree_skb+0xe9/0x150
 kfree_skb_reason+0x7b/0x110
 skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
 ? mark_lock.part.0+0x8a/0x520
...

trace_drop_common() also disables interrupts, but this is a minor issue
because we could easily replace it with a local_lock.

Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
context.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e; https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334; https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0
CVE: CVE-2024-40982
Published: 2024-07-12
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-40983
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: force a dst refcount before doing decryption

As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before
entering the xfrm type handlers"):

"Crypto requests might return asynchronous. In this case we leave the
 rcu protected region, so force a refcount on the skb's destination
 entry before we enter the xfrm type input/output handlers."

On TIPC decryption path it has the same problem, and skb_dst_force()
should be called before doing decryption to avoid a possible crash.

Shuang reported this issue when this warning is triggered:

  [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
  [] Workqueue: crypto cryptd_queue_worker
  [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Call Trace:
  [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
  [] tipc_rcv+0xcf5/0x1060 [tipc]
  [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
  [] cryptd_aead_crypt+0xdb/0x190
  [] cryptd_queue_worker+0xed/0x190
  [] process_one_work+0x93d/0x17e0
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2ebe8f840c7450ecbfca9d18ac92e9ce9155e269; https://git.kernel.org/stable/c/3eb1b39627892c4e26cb0162b75725aa5fcc60c8; https://git.kernel.org/stable/c/623c90d86a61e3780f682b32928af469c66ec4c2
CVE: CVE-2024-40984
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
purpose of this commit was to stop memory mappings for operation
regions from overlapping page boundaries, as it can trigger warnings
if different page attributes are present.

However, it was found that when this situation arises, mapping
continues until the boundary's end, but there is still an attempt to
read/write the entire length of the map, leading to a NULL pointer
deference. For example, if a four-byte mapping request is made but
only one byte is mapped because it hits the current page boundary's
end, a four-byte read/write attempt is still made, resulting in a NULL
pointer deference.

Instead, map the entire length, as the ACPI specification does not
mandate that it must be within the same page boundary. It is
permissible for it to be mapped across different regions.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3; https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98; https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d
CVE: CVE-2024-40985
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net/tcp_ao: Don't leak ao_info on error-path

It seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on
version 5 [1] of TCP-AO patches. Quite frustrative that having all these
selftests that I've written, running kmemtest & kcov was always in todo.

[1]: https://lore.kernel.org/netdev/[PII_REDACTED]3335.800122-5-dima@arista.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/ebaa7d3c26332330a48f9a15f8e518d526cc0f21; https://git.kernel.org/stable/c/f9ae848904289ddb16c7c9e4553ed4c64300de49; https://git.kernel.org/stable/c/ebaa7d3c26332330a48f9a15f8e518d526cc0f21
CVE: CVE-2024-40986
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()

Requests the vchan lock before using xdma->stop_request.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/462237d2d93fc9e9221d1cf9f773954d27da83c0; https://git.kernel.org/stable/c/8e1f54e4a3f3207c9dc68bb5000603b75802e7f0; https://git.kernel.org/stable/c/462237d2d93fc9e9221d1cf9f773954d27da83c0
CVE: CVE-2024-40987
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumo_vid_mapping_entry.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1c44f7759a5650acf8f13d3e0a184d09e03be9e4; https://git.kernel.org/stable/c/4ad7d49059358ceadd352b4e2511425bdb68f400; https://git.kernel.org/stable/c/4d020c1dbd2b2304f44d003e6de956ae570049dc
CVE: CVE-2024-40988
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumo_vid_mapping_entry.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-119
References: https://git.kernel.org/stable/c/07e8f15fa16695cf4c90e89854e59af4a760055b; https://git.kernel.org/stable/c/468a50fd46a09bba7ba18a11054ae64b6479ecdc; https://git.kernel.org/stable/c/9e57611182a817824a17b1c3dd300ee74a174b42
CVE: CVE-2024-40989
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Disassociate vcpus from redistributor region on teardown

When tearing down a redistributor region, make sure we don't have
any dangling pointer to that region stored in a vcpu.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0d92e4a7ffd5c42b9fa864692f82476c0bf8bcc8; https://git.kernel.org/stable/c/152b4123f21e6aff31cea01158176ad96a999c76; https://git.kernel.org/stable/c/48bb62859d47c5c4197a8c01128d0fa4f46ee58c
CVE: CVE-2024-40990
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Add check for srq max_sge attribute

max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn't exceed maximum allowed value
before using it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1e692244bf7dd827dd72edc6c4a3b36ae572f03c; https://git.kernel.org/stable/c/36ab7ada64caf08f10ee5a114d39964d1f91e81d; https://git.kernel.org/stable/c/4ab99e3613139f026d2d8ba954819e2876120ab3
CVE: CVE-2024-40991
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id()

The of_k3_udma_glue_parse_chn_by_id() helper function erroneously
invokes "of_node_put()" on the "udmax_np" device-node passed to it,
without having incremented its reference count at any point. Fix it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a5ab5f413d1e4c7ed5f64271b025f[PII_REDACTED]e; https://git.kernel.org/stable/c/ba27e9d2207784da748b19170a2e56bd7770bd81; https://git.kernel.org/stable/c/a5ab5f413d1e4c7ed5f64271b025f[PII_REDACTED]e
CVE: CVE-2024-40992
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix responder length checking for UD request packets

According to the IBA specification:
If a UD request packet is detected with an invalid length, the request
shall be an invalid request and it shall be silently dropped by
the responder. The responder then waits for a new request packet.

commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking")
defers responder length check for UD QPs in function `copy_data`.
But it introduces a regression issue for UD QPs.

When the packet size is too large to fit in the receive buffer.
`copy_data` will return error code -EINVAL. Then `send_data_in`
will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into
ERROR state.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/163868ec1f6c610d16da9e458fe1dd7d5de97341; https://git.kernel.org/stable/c/943c94f41dfe36536dc9aaa12c9efdf548ceb996; https://git.kernel.org/stable/c/f67ac0061c7614c1548963d3ef1ee1606efd8636
CVE: CVE-2024-40993
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: Fix suspicious rcu_dereference_protected()

When destroying all sets, we are either in pernet exit phase or
are executing a "destroy all sets command" from userspace. The latter
was taken into account in ip_set_dereference() (nfnetlink mutex is held),
but the former was not. The patch adds the required check to
rcu_dereference_protected() in ip_set_dereference().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3799d02ae4208af08e81310770d8754863a246a1; https://git.kernel.org/stable/c/3fc09e1ca854bc234e007a56e0f7431f5e2defb5; https://git.kernel.org/stable/c/523bed6489e089dd8040e72453fb79da47b144c2
CVE: CVE-2024-40994
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: fix integer overflow in max_vclocks_store

On 32bit systems, the "4 * max" multiply can overflow.  Use kcalloc()
to do the allocation to prevent this.
CVSS Score: 7.8 (HIGH)
CWE: CWE-190
References: https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e; https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f; https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0
CVE: CVE-2024-40995
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()

syzbot found hanging tasks waiting on rtnl_lock [1]

A reproducer is available in the syzbot bug.

When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.

Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.

[1]

INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5409 [inline]
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
__schedule_loop kernel/sched/core.c:6823 [inline]
schedule+0xe7/0x350 kernel/sched/core.c:6838
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
wiphy_lock include/net/cfg80211.h:5953 [inline]
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74; https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da; https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2
CVE: CVE-2024-40996
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Avoid splat in pskb_pull_reason

syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug
hint in pskb_may_pull.

We'd like to retain this debug check because it might hint at integer
overflows and other issues (kernel code should pull headers, not huge
value).

In bpf case, this splat isn't interesting at all: such (nonsensical)
bpf programs are typically generated by a fuzzer anyway.

Do what Eric suggested and suppress such warning.

For CONFIG_DEBUG_NET=n we don't need the extra check because
pskb_may_pull will do the right thing: return an error without the
WARN() backtrace.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/2bbe3e5a2f4ef69d13be54f1cf895b[PII_REDACTED]; https://git.kernel.org/stable/c/5e90258303a358e88737afb5048bee9113beea3a; https://git.kernel.org/stable/c/7f9644782c559635bd676c12c59389a34ed7c866
CVE: CVE-2024-40997
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate: fix memory leak on CPU EPP exit

The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
not freed in the analogous exit function, so fix that.

[ rjw: Subject and changelog edits ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd; https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582; https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81