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

ax25: Fix refcount imbalance on inbound connections

When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.

A typical call trace for the above situation will start with one of the
following errors:

    refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.

And will then have a trace like:

    Call Trace:
    <TASK>
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]

On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:

    unregister_netdevice: waiting for ax0 to become free. Usage count = 0

This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which is ultimately decremented in
ax25_release().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3c34fb0bd4a4237592c5ecb5b2e2531900c55774; https://git.kernel.org/stable/c/52100fd74ad07b53a4666feafff1cd11436362d3; https://git.kernel.org/stable/c/a723a6c8d4831cc8e2c7b0c9f3f0c010d4671964
CVE: CVE-2024-40911
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: Lock wiphy in cfg80211_get_station

Wiphy should be locked before calling rdev_get_station() (see lockdep
assert in ieee80211_get_station()).

This fixes the following kernel NULL dereference:

 Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
 Mem abort info:
   ESR = 0x[PII_REDACTED]000006
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x06: level 2 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000006
   CM = 0, WnR = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=[PII_REDACTED]
 [[PII_REDACTED]] pgd=[PII_REDACTED]dca003, p4d=[PII_REDACTED]dca003, pud=[PII_REDACTED]8e9003, pmd=[PII_REDACTED]
 Internal error: Oops: [PII_REDACTED] [#1] SMP
 Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath
 CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705
 Hardware name: RPT (r1) (DT)
 Workqueue: bat_events batadv_v_elp_throughput_metric_update
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
 lr : sta_set_sinfo+0xcc/0xbd4
 sp : ffff000007b43ad0
 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98
 x26: ffff[PII_REDACTED]80 x25: ffff[PII_REDACTED]80 x24: ffff00000294c000
 x23: [PII_REDACTED] x22: ffff000007b43c90 x21: ffff800008898acc
 x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: [PII_REDACTED]
 x17: 445946354d552d78 x16: 62661f[PII_REDACTED] x15: 57464f445946354d
 x14: [PII_REDACTED] x13:[PII_REDACTED]0000e3 x12: d5f0acbcebea978e
 x11:[PII_REDACTED]0000e3 x10:[PII_REDACTED]48fe41 x9 : [PII_REDACTED]
 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : [PII_REDACTED]
 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90
 x2 : ffff00000294ca98 x1 : ffff[PII_REDACTED]20 x0 : [PII_REDACTED]
 Call trace:
  ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
  sta_set_sinfo+0xcc/0xbd4
  ieee80211_get_station+0x2c/0x44
  cfg80211_get_station+0x80/0x154
  batadv_v_elp_get_throughput+0x138/0x1fc
  batadv_v_elp_throughput_metric_update+0x1c/0xa4
  process_one_work+0x1ec/0x414
  worker_thread+0x70/0x46c
  kthread+0xdc/0xe0
  ret_from_fork+0x10/0x20
 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)

This happens because STA has time to disconnect and reconnect before
batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In
this situation, ath10k_sta_state() can be in the middle of resetting
arsta data when the work queue get chance to be scheduled and ends up
accessing it. Locking wiphy prevents that.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a; https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba; https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae
CVE: CVE-2024-40913
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: defer exposing anon_fd until after copy_to_user() succeeds

After installing the anonymous fd, we can now see it in userland and close
it. However, at this point we may not have gotten the reference count of
the cache, but we will put it during colse fd, so this may cause a cache
UAF.

So grab the cache reference count before fd_install(). In addition, by
kernel convention, fd is taken over by the user land after fd_install(),
and the kernel should not call close_fd() after that, i.e., it should call
fd_install() after everything is ready, thus fd_install() is called after
copy_to_user() succeeds.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4b4391e77a6bf24cba2ef1590e113d9b73b11039; https://git.kernel.org/stable/c/b9f58cdae6a364a3270fd6b6a46e0fd4f7f8ce32; https://git.kernel.org/stable/c/d2d3eb377a5d081bf2bed177d354a4f59b74da88
CVE: CVE-2024-40914
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: don't unpoison huge_zero_folio

When I did memory failure tests recently, below panic occurs:

 kernel BUG at include/linux/mm.h:1135!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14
 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
 RAX:[PII_REDACTED]00003e RBX: [PII_REDACTED] RCX: ffff88f61fc5c9c8
 RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff88f61fc5c9c0
 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: [PII_REDACTED]
 R10:[PII_REDACTED]0030ea R11: ffffffff9a9405f0 R12: [PII_REDACTED]
 R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff88e703c4ac00
 FS:  [PII_REDACTED](0000) GS:ffff88f61fc40000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4:[PII_REDACTED]0006f0
 Call Trace:
  <TASK>
  do_shrink_slab+0x14f/0x6a0
  shrink_slab+0xca/0x8c0
  shrink_node+0x2d0/0x7d0
  balance_pgdat+0x33a/0x720
  kswapd+0x1f3/0x410
  kthread+0xd5/0x100
  ret_from_fork+0x2f/0x50
  ret_from_fork_asm+0x1a/0x30
  </TASK>
 Modules linked in: mce_inject hwpoison_inject
 ---[ end trace [PII_REDACTED] ]---
 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
 RAX:[PII_REDACTED]00003e RBX: [PII_REDACTED] RCX: ffff88f61fc5c9c8
 RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff88f61fc5c9c0
 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: [PII_REDACTED]
 R10:[PII_REDACTED]0030ea R11: ffffffff9a9405f0 R12: [PII_REDACTED]
 R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff88e703c4ac00
 FS:  [PII_REDACTED](0000) GS:ffff88f61fc40000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4:[PII_REDACTED]0006f0

The root cause is that HWPoison flag will be set for huge_zero_folio
without increasing the folio refcnt.  But then unpoison_memory() will
decrease the folio refcnt unexpectedly as it appears like a successfully
hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when
releasing huge_zero_folio.

Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. 
We're not prepared to unpoison huge_zero_folio yet.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d73477af964dbd7396163a13817baf13940bca9; https://git.kernel.org/stable/c/688bb46ad339497b5b7f527b6636d2afe04b46af; https://git.kernel.org/stable/c/b2494506f30675245a3e6787281f79601af087bf
CVE: CVE-2024-40915
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context

__kernel_map_pages() is a debug function which clears the valid bit in page
table entry for deallocated pages to detect illegal memory accesses to
freed pages.

This function set/clear the valid bit using __set_memory(). __set_memory()
acquires init_mm's semaphore, and this operation may sleep. This is
problematic, because  __kernel_map_pages() can be called in atomic context,
and thus is illegal to sleep. An example warning that this causes:

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
preempt_count: 2, expected: 0
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[<ffffffff800060dc>] dump_backtrace+0x1c/0x24
[<ffffffff8091ef6e>] show_stack+0x2c/0x38
[<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72
[<ffffffff8092bb24>] dump_stack+0x14/0x1c
[<ffffffff8003b7ac>] __might_resched+0x104/0x10e
[<ffffffff8003b7f4>] __might_sleep+0x3e/0x62
[<ffffffff8093276a>] down_write+0x20/0x72
[<ffffffff8000cf00>] __set_memory+0x82/0x2fa
[<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4
[<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a
[<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba
[<ffffffff80011904>] copy_process+0x72c/0x17ec
[<ffffffff80012ab4>] kernel_clone+0x60/0x2fe
[<ffffffff80012f62>] kernel_thread+0x82/0xa0
[<ffffffff8003552c>] kthreadd+0x14a/0x1be
[<ffffffff809357de>] ret_from_fork+0xe/0x1c

Rewrite this function with apply_to_existing_page_range(). It is fine to
not have any locking, because __kernel_map_pages() works with pages being
allocated/deallocated and those pages are not changed by anyone else in the
meantime.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/8661a7af[PII_REDACTED]0863ad1a0983173f84b5eb; https://git.kernel.org/stable/c/919f8626099d9909b9a9620b05e8c8ab06581876; https://git.kernel.org/stable/c/d5257ceb19d[PII_REDACTED]4866421f425aea42915
CVE: CVE-2024-40917
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

memblock: make memblock_set_node() also warn about use of MAX_NUMNODES

On an (old) x86 system with SRAT just covering space above 4Gb:

    ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug

the commit referenced below leads to this NUMA configuration no longer
being refused by a CONFIG_NUMA=y kernel (previously

    NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.
    No NUMA configuration found
    Faking a node at [mem 0x[PII_REDACTED]000000-0x000000027fffffff]

was seen in the log directly after the message quoted above), because of
memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This
in turn led to memblock_alloc_range_nid()'s warning about MAX_NUMNODES
triggering, followed by a NULL deref in memmap_init() when trying to
access node 64's (NODE_SHIFT=6) node data.

To compensate said change, make memblock_set_node() warn on and adjust
a passed in value of MAX_NUMNODES, just like various other functions
already do.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/22f742b8f738918f683198a18ec3c691acda14c4; https://git.kernel.org/stable/c/4ddb7f966f3d06fcf1ba5ee298af6714b593584b; https://git.kernel.org/stable/c/e0eec24e2e199873f43df99ec39773ad3af2bff7
CVE: CVE-2024-40919
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()

In case of token is released due to token->state == BNXT_HWRM_DEFERRED,
released token (set to NULL) is used in log messages. This issue is
expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But
this error code is returned by recent firmware. So some firmware may not
return it. This may lead to NULL pointer dereference.
Adjust this issue by adding token pointer check.

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

net: bridge: mst: fix suspicious rcu usage in br_mst_set_state

I converted br_mst_set_state to RCU to avoid a vlan use-after-free
but forgot to change the vlan group dereference helper. Switch to vlan
group RCU deref helper to fix the suspicious rcu usage warning.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/406bfc04b01ee47e4c626f77ecc7d9f85135b166; https://git.kernel.org/stable/c/546ceb1dfdac866648ec959cbc71d9525bd73462; https://git.kernel.org/stable/c/7caefa2771722e65496d85b62e1dc4442b7d1345
CVE: CVE-2024-40921
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state

Pass the already obtained vlan group pointer to br_mst_vlan_set_state()
instead of dereferencing it again. Each caller has already correctly
dereferenced it for their context. This change is required for the
following suspicious RCU dereference fix. No functional changes
intended.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09f4337c27f5bdeb8646a6db91488cc2f7d537ff; https://git.kernel.org/stable/c/36c92936e868601fa1f43da6758cf[PII_REDACTED]9; https://git.kernel.org/stable/c/a6cc9e9a651b9861efa068c164ee62dfba68c6ca
CVE: CVE-2024-40922
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/rsrc: don't lock while !TASK_RUNNING

There is a report of io_rsrc_ref_quiesce() locking a mutex while not
TASK_RUNNING, which is due to forgetting restoring the state back after
io_run_task_work_sig() and attempts to break out of the waiting loop.

do not call blocking ops when !TASK_RUNNING; state=1 set at
[<ffffffff815d2494>] prepare_to_wait+0xa4/0x380
kernel/sched/wait.c:237
WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099
__might_sleep+0x114/0x160 kernel/sched/core.c:10099
RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099
Call Trace:
 <TASK>
 __mutex_lock_common kernel/locking/mutex.c:585 [inline]
 __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752
 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253
 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799
 __io_uring_register io_uring/register.c:424 [inline]
 __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0c9df3df0c888d9ec8d11a68474a4aa04d371cff; https://git.kernel.org/stable/c/4429c6c77e176a4c5aa7a3bbd1632f9fc0582518; https://git.kernel.org/stable/c/54559642b96116b45e4b5ca7fd9f7835b8561272
CVE: CVE-2024-40924
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/dpt: Make DPT object unshrinkable

In some scenarios, the DPT object gets shrunk but
the actual framebuffer did not and thus its still
there on the DPT's vm->bound_list. Then it tries to
rewrite the PTEs via a stale CPU mapping. This causes panic.

[vsyrjala: Add TODO comment]
(cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]66f0e5f2e50356b5823f76dabfe86e; https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1; https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb
CVE: CVE-2024-40925
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

block: fix request.queuelist usage in flush

Friedrich Weber reported a kernel crash problem and bisected to commit
81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine").

The root cause is that we use "list_move_tail(&rq->queuelist, pending)"
in the PREFLUSH/POSTFLUSH sequences. But rq->queuelist.next == xxx since
it's popped out from plug->cached_rq in __blk_mq_alloc_requests_batch().
We don't initialize its queuelist just for this first request, although
the queuelist of all later popped requests will be initialized.

Fix it by changing to use "list_add_tail(&rq->queuelist, pending)" so
rq->queuelist doesn't need to be initialized. It should be ok since rq
can't be on any list when PREFLUSH or POSTFLUSH, has no move actually.

Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in
flush state machine") also has another requirement that no drivers would
touch rq->queuelist after blk_mq_end_request() since we will reuse it to
add rq to the post-flush pending list in POSTFLUSH. If this is not true,
we will have to revert that commit IMHO.

This updated version adds "list_del_init(&rq->queuelist)" in flush rq
callback since the dm layer may submit request of a weird invalid format
(REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add
if without this "list_del_init(&rq->queuelist)". The weird invalid format
problem should be fixed in dm layer.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/87907bd69721a8506618a954d41a1de3040e88aa; https://git.kernel.org/stable/c/d0321c812d89c5910d8da8e4b10c891c6b96ff70; https://git.kernel.org/stable/c/fe1e395563ccb051e9dbd8fa99859f5caaad2e71
CVE: CVE-2024-40926
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: don't attempt to schedule hpd_work on headless cards

If the card doesn't have display hardware, hpd_work and hpd_lock are
left uninitialized which causes BUG when attempting to schedule hpd_work
on runtime PM resume.

Fix it by adding headless flag to DRM and skip any hpd if it's set.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/227349998e5740f14d531b0f0d704e66b1ed3c2f; https://git.kernel.org/stable/c/b96a225377b6602299a03d2ce3c289b68cd41bb7; https://git.kernel.org/stable/c/227349998e5740f14d531b0f0d704e66b1ed3c2f
CVE: CVE-2024-40928
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()

Clang static checker (scan-build) warning:
net/ethtool/ioctl.c:line 2233, column 2
Called function pointer is null (null dereference).

Return '-EOPNOTSUPP' when 'ops->get_ethtool_phy_stats' is NULL to fix
this typo error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0dcc53abf58d572d34c5313de85f607cd33fc691; https://git.kernel.org/stable/c/25504f7fe60058b2a9553a9e424fb7dd9683843e; https://git.kernel.org/stable/c/6548d543a27449a1a3d8079925de93f5764d6f22
CVE: CVE-2024-40929
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: check n_ssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even
though n_ssids is 0. Accessing the pointer in this case will cuase an
out-of-bound access. Fix this by checking n_ssids first.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/29a18d56bd64b95bd10bda4afda[PII_REDACTED]82a; https://git.kernel.org/stable/c/3c4771091ea8016c[PII_REDACTED]916f722dd8833b; https://git.kernel.org/stable/c/60d62757df30b74bf397a2847a6db7385c6ee281
CVE: CVE-2024-40930
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: validate HE operation element parsing

Validate that the HE operation element has the correct
length before parsing it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4dc3a3893dae5a7f73e5809273aca0f1f3548d55; https://git.kernel.org/stable/c/f15e3e13e14cc5ae8f950c16efe706add18ac8e2; https://git.kernel.org/stable/c/4dc3a3893dae5a7f73e5809273aca0f1f3548d55
CVE: CVE-2024-40931
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: ensure snd_una is properly initialized on connect

This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
is properly initialized on connect"). It turns out that syzkaller can
trigger the retransmit after fallback and before processing any other
incoming packet - so that snd_una is still left uninitialized.

Address the issue explicitly initializing snd_una together with snd_nxt
and write_seq.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde; https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726; https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3
CVE: CVE-2024-40932
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/exynos/vidi: fix memory leak in .get_modes()

The duplicated EDID is never freed. Fix it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003; https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e; https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819
CVE: CVE-2024-40933
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: temperature: mlx90635: Fix ERR_PTR dereference in mlx90635_probe()

When devm_regmap_init_i2c() fails, regmap_ee could be error pointer,
instead of checking for IS_ERR(regmap_ee), regmap is checked which looks
like a copy paste error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/5a5595ae8cc7cdaa1a10b56a26ddbe3429245c6c; https://git.kernel.org/stable/c/a23c14b062d8800a2192077d83273bbfe6c7552d; https://git.kernel.org/stable/c/5a5595ae8cc7cdaa1a10b56a26ddbe3429245c6c
CVE: CVE-2024-40934
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()

Fix a memory leak on logi_dj_recv_send_report() error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/15122dc140d82c51c216535c57b044c4587aae45; https://git.kernel.org/stable/c/1df2ead5dfad5f8f92467bd94889392d53100b98; https://git.kernel.org/stable/c/789c99a1d7d2c8f6096d75fc[PII_REDACTED]ec9ea0