deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26665
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

tunnels: fix out of bounds access when building IPv6 PMTU error

If the ICMPv6 error is built from a non-linear skb we get the following
splat,

  BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
  Read of size 4 at addr ffff88811d402c80 by task netperf/820
  CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
  ...
   kasan_report+0xd8/0x110
   do_csum+0x220/0x240
   csum_partial+0xc/0x20
   skb_tunnel_check_pmtu+0xeb9/0x3280
   vxlan_xmit_one+0x14c2/0x4080
   vxlan_xmit+0xf61/0x5c00
   dev_hard_start_xmit+0xfb/0x510
   __dev_queue_xmit+0x7cd/0x32a0
   br_dev_queue_push_xmit+0x39d/0x6a0

Use skb_checksum instead of csum_partial who cannot deal with non-linear
SKBs.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1; https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab; https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06
CVE: CVE-2024-26666
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix RCU use in TDLS fast-xmit

This looks up the link under RCU protection, but isn't
guaranteed to actually have protection. Fix that.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/9480adfe4e0f0319b9da04b44e4eebd5ad07e0cd; https://git.kernel.org/stable/c/c255c3b653c6e8b52ac658c305e2fece2825f7ad; https://git.kernel.org/stable/c/fc3432ae8232ff4025e7c55012dd88db0e3d18eb
CVE: CVE-2024-26667
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup

The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback
in case of YUV output") introduced a smatch warning about another
conditional block in dpu_encoder_helper_phys_cleanup() which had assumed
hw_pp will always be valid which may not necessarily be true.

Lets fix the other conditional block by making sure hw_pp is valid
before dereferencing it.

Patchwork: https://patchwork.freedesktop.org/patch/574878/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8; https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52; https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2
CVE: CVE-2024-26668
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_limit: reject configurations that cause integer overflow

Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.

Its better to reject this rather than having incorrect ratelimit.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a; https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1; https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
CVE: CVE-2024-26670
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD

Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn't
quite right, as it is supposed to be applied after the last explicit
memory access, but is immediately followed by an LDR.

The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to
handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,
which are described in:

* https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en
* https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en

In both cases the workaround is described as:

| If pagetable isolation is disabled, the context switch logic in the
| kernel can be updated to execute the following sequence on affected
| cores before exiting to EL0, and after all explicit memory accesses:
|
| 1. A non-shareable TLBI to any context and/or address, including
|    unused contexts or addresses, such as a `TLBI VALE1 Xzr`.
|
| 2. A DSB NSH to guarantee completion of the TLBI.

The important part being that the TLBI+DSB must be placed "after all
explicit memory accesses".

Unfortunately, as-implemented, the TLBI+DSB is immediately followed by
an LDR, as we have:

| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD
| 	tlbi	vale1, xzr
| 	dsb	nsh
| alternative_else_nop_endif
| alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0
| 	ldr	lr, [sp, #S_LR]
| 	add	sp, sp, #PT_REGS_SIZE		// restore sp
| 	eret
| alternative_else_nop_endif
|
| [ ... KPTI exception return path ... ]

This patch fixes this by reworking the logic to place the TLBI+DSB
immediately before the ERET, after all explicit memory accesses.

The ERET is currently in a separate alternative block, and alternatives
cannot be nested. To account for this, the alternative block for
ARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch
to skip the KPTI logic, with the new shape of the logic being:

| alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0
| 	[ ... KPTI exception return path ... ]
| .L_skip_tramp_exit_\@:
|
| 	ldr	lr, [sp, #S_LR]
| 	add	sp, sp, #PT_REGS_SIZE		// restore sp
|
| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD
| 	tlbi	vale1, xzr
| 	dsb	nsh
| alternative_else_nop_endif
| 	eret

The new structure means that the workaround is only applied when KPTI is
not in use; this is fine as noted in the documented implications of the
erratum:

| Pagetable isolation between EL0 and higher level ELs prevents the
| issue from occurring.

... and as per the workaround description quoted above, the workaround
is only necessary "If pagetable isolation is disabled".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/58eb5c07f41704464b9acc09ab0707b6769db6c0; https://git.kernel.org/stable/c/832dd634bd1b4e3bbe9f10b9c9ba5db6f6f2b97f; https://git.kernel.org/stable/c/baa0aaac[PII_REDACTED]e0d60c41cd34a0c3c3477
CVE: CVE-2024-26671
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix IO hang from sbitmap wakeup race

In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
with the following blk_mq_get_driver_tag() in case of getting driver
tag failure.

Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
blk_mq_mark_tag_wait() can't get driver tag successfully.

This issue can be reproduced by running the following test in loop, and
fio hang can be observed in < 30min when running it on my test VM
in laptop.

	modprobe -r scsi_debug
	modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
	dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
	fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
       		--runtime=100 --numjobs=40 --time_based --name=test \
        	--ioengine=libaio

Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56; https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed; https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
CVE: CVE-2024-26672
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'

Fixes the below:

drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368)

357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev,
				     enum amdgpu_mca_error_type type,
358                                  int idx, struct mca_bank_entry *entry)
359 {
360         const struct amdgpu_mca_smu_funcs *mca_funcs =
						adev->mca.mca_funcs;
361         int count;
362
363         switch (type) {
364         case AMDGPU_MCA_ERROR_TYPE_UE:
365                 count = mca_funcs->max_ue_count;

mca_funcs is dereferenced here.

366                 break;
367         case AMDGPU_MCA_ERROR_TYPE_CE:
368                 count = mca_funcs->max_ce_count;

mca_funcs is dereferenced here.

369                 break;
370         default:
371                 return -EINVAL;
372         }
373
374         if (idx >= count)
375                 return -EINVAL;
376
377         if (mca_funcs && mca_funcs->mca_get_mca_entry)
	        ^^^^^^^^^

Checked too late!
CVSS Score: 7.1 (HIGH)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4f32504a2f85a7b40fe[PII_REDACTED]1f48e9c0c0; https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53; https://git.kernel.org/stable/c/4f32504a2f85a7b40fe[PII_REDACTED]1f48e9c0c0
CVE: CVE-2024-26673
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations

- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a
  mandatory attribute for this object.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98; https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8; https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
CVE: CVE-2024-26674
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups

During memory error injection test on kernels >= v6.4, the kernel panics
like below. However, this issue couldn't be reproduced on kernels <= v6.3.

  mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd[PII_REDACTED]0134
  mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20}
  mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86
  mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME[PII_REDACTED] SOCKET 1 APIC 211 microcode 80001490
  mce: [Hardware Error]: Run the above through 'mcelog --ascii'
  mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
  Kernel panic - not syncing: Fatal local machine check

The MCA code can recover from an in-kernel #MC if the fixup type is
EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to
access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT
the only thing that is raised for an in-kernel #MC is a panic.

ex_handler_uaccess() would warn if users gave a non-canonical addresses
(with bit 63 clear) to {get, put}_user(), which was unexpected.

Therefore, commit

  b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")

replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user()
fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic.

Commit

  6014bc27561f ("x86-64: make access_ok() independent of LAM")

added the check gp_fault_address_ok() right before the WARN_ONCE() in
ex_handler_uaccess() to not warn about non-canonical user addresses due
to LAM.

With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user()
exception fixups in order to be able to handle in-kernel MCEs correctly
again.

  [ bp: Massage commit message. ]
CVSS Score: 7.1 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/2aed1b6c33afd8599d01c6532bbecb829480a674; https://git.kernel.org/stable/c/2da241c5ed78d0978228a[PII_REDACTED]fe1a60eca; https://git.kernel.org/stable/c/8eed4e00a370b37b4e5985ed983dccedd555ea9d
CVE: CVE-2024-26675
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

ppp_async: limit MRU to 64K

syzbot triggered a warning [1] in __alloc_pages():

WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)

Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")

Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)

[1]:

 WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events_unbound flush_to_ldisc
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
sp : ffff[PII_REDACTED]80
x29: ffff[PII_REDACTED]60 x28: ffff[PII_REDACTED]a0 x27: dfff[PII_REDACTED]00
x26: ffff70001272ceb4 x25: [PII_REDACTED] x24: ffff[PII_REDACTED]c0
x23: [PII_REDACTED] x22: [PII_REDACTED] x21: 1ffff0001272ceb8
x20: ffff[PII_REDACTED]e0 x19: [PII_REDACTED] x18: ffff[PII_REDACTED]20
x17: ffff800083bded5c x16: ffff80008ac97500 x15: [PII_REDACTED]
x14: 1ffff0001272cebc x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : [PII_REDACTED]
x8 : ffff800091c91000 x7 : [PII_REDACTED] x6 :[PII_REDACTED]00003f
x5 : 00000000ffffffff x4 : [PII_REDACTED] x3 : [PII_REDACTED]
x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff[PII_REDACTED]e0
Call trace:
  __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
  __alloc_pages_node include/linux/gfp.h:238 [inline]
  alloc_pages_node include/linux/gfp.h:261 [inline]
  __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
  __do_kmalloc_node mm/slub.c:3969 [inline]
  __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
  kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
  __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
  __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
  netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
  dev_alloc_skb include/linux/skbuff.h:3248 [inline]
  ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
  ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
  tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
  tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
  receive_buf drivers/tty/tty_buffer.c:444 [inline]
  flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
  process_one_work+0x694/0x1204 kernel/workqueue.c:2633
  process_scheduled_works kernel/workqueue.c:2706 [inline]
  worker_thread+0x938/0xef4 kernel/workqueue.c:2787
  kthread+0x288/0x310 kernel/kthread.c:388
  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8; https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16; https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed
CVE: CVE-2024-26677
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix delayed ACKs to not set the reference serial number

Fix the construction of delayed ACKs to not set the reference serial number
as they can't be used as an RTT reference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2; https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae; https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef
CVE: CVE-2024-26678
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section

The .compat section is a dummy PE section that contains the address of
the 32-bit entrypoint of the 64-bit kernel image if it is bootable from
32-bit firmware (i.e., CONFIG_EFI_MIXED=y)

This section is only 8 bytes in size and is only referenced from the
loader, and so it is placed at the end of the memory view of the image,
to avoid the need for padding it to 4k, which is required for sections
appearing in the middle of the image.

Unfortunately, this violates the PE/COFF spec, and even if most EFI
loaders will work correctly (including the Tianocore reference
implementation), PE loaders do exist that reject such images, on the
basis that both the file and memory views of the file contents should be
described by the section headers in a monotonically increasing manner
without leaving any gaps.

So reorganize the sections to avoid this issue. This results in a slight
padding overhead (< 4k) which can be avoided if desired by disabling
CONFIG_EFI_MIXED (which is only needed in rare cases these days)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0a962f2fbaa976af9eed21d0306370cded485787; https://git.kernel.org/stable/c/1ad55cecf22f05f1c884adf63cc09d3c3e609ebf; https://git.kernel.org/stable/c/4adeeff8c12321cd453412a659c3c0eeb9bb2397
CVE: CVE-2024-26679
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

inet: read sk->sk_family once in inet_recv_error()

inet_recv_error() is called without holding the socket lock.

IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
socket option and trigger a KCSAN warning.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830; https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41; https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2
CVE: CVE-2024-26680
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: Fix DMA mapping for PTP hwts ring

Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
for PTP HWTS ring but then generic aq_ring_free() does not take this
into account.
Create and use a specific function to free HWTS ring to fix this
issue.

Trace:
[  215.351607] ------------[ cut here ]------------
[  215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
[  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
...
[  215.581176] Call Trace:
[  215.583632]  <TASK>
[  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df
[  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df
[  215.594497]  ? debug_dma_free_coherent+0x196/0x210
[  215.599305]  ? check_unmap+0xa6f/0x2360
[  215.603147]  ? __warn+0xca/0x1d0
[  215.606391]  ? check_unmap+0xa6f/0x2360
[  215.610237]  ? report_bug+0x1ef/0x370
[  215.613921]  ? handle_bug+0x3c/0x70
[  215.617423]  ? exc_invalid_op+0x14/0x50
[  215.621269]  ? asm_exc_invalid_op+0x16/0x20
[  215.625480]  ? check_unmap+0xa6f/0x2360
[  215.629331]  ? mark_lock.part.0+0xca/0xa40
[  215.633445]  debug_dma_free_coherent+0x196/0x210
[  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10
[  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0
[  215.648060]  dma_free_attrs+0x6d/0x130
[  215.651834]  aq_ring_free+0x193/0x290 [atlantic]
[  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]
...
[  216.127540] ---[ end trace 6467e5964dd2640b ]---
[  216.132160] DMA-API: Mapped at:
[  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0
[  216.132165]  dma_alloc_attrs+0xf5/0x1b0
[  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
[  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
[  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56; https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887; https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12
CVE: CVE-2024-26682
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: improve CSA/ECSA connection refusal

As mentioned in the previous commit, we pretty quickly found
that some APs have ECSA elements stuck in their probe response,
so using that to not attempt to connect while CSA is happening
we never connect to such an AP.

Improve this situation by checking more carefully and ignoring
the ECSA if cfg80211 has previously detected the ECSA element
being stuck in the probe response.

Additionally, allow connecting to an AP that's switching to a
channel it's already using, unless it's using quiet mode. In
this case, we may just have to adjust bandwidth later. If it's
actually switching channels, it's better not to try to connect
in the middle of that.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/35e2385dbe787936c793d70755a5177d267a40aa; https://git.kernel.org/stable/c/ea88bde8e3fefbe4268f6991375dd629895a090a; https://git.kernel.org/stable/c/35e2385dbe787936c793d70755a5177d267a40aa
CVE: CVE-2024-26683
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: detect stuck ECSA element in probe resp

We recently added some validation that we don't try to
connect to an AP that is currently in a channel switch
process, since that might want the channel to be quiet
or we might not be able to connect in time to hear the
switching in a beacon. This was in commit c09c4f31998b
("wifi: mac80211: don't connect to an AP while it's in
a CSA process").

However, we promptly got a report that this caused new
connection failures, and it turns out that the AP that
we now cannot connect to is permanently advertising an
extended channel switch announcement, even with quiet.
The AP in question was an Asus RT-AC53, with firmware
3.0.0.4.380_10760-g21a5898.

As a first step, attempt to detect that we're dealing
with such a situation, so mac80211 can use this later.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/177fbbcb4ed6b306c1626a277fac3fb1c495a4c7; https://git.kernel.org/stable/c/ce112c941c2b172afba3e913a90c380647d53975; https://git.kernel.org/stable/c/177fbbcb4ed6b306c1626a277fac3fb1c495a4c7
CVE: CVE-2024-26684
Published: 2024-04-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: xgmac: fix handling of DPP safety error for DMA channels

Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
XGMAC core") checks and reports safety errors, but leaves the
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
a storm of interrupt.
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37; https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2; https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3
CVE: CVE-2024-28226
Published: 2024-04-02
Description: in OpenHarmony v4.0.0 and prior versions allow a remote attacker cause DOS through improper input.
CVSS Score: 8.1 (HIGH)
CWE: CWE-20
References: https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md; https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md
CVE: CVE-2024-28951
Published: 2024-04-02
Description: in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution in pre-installed apps through use after free.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416, CWE-416
References: https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md; https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md
CVE: CVE-2024-29074
Published: 2024-04-02
Description: in OpenHarmony v3.2.4 and prior versions allow a local attacker arbitrary code execution in any apps through improper input.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-20
References: https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md; https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md