deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-35180
Published: 2024-05-21
Description: OMERO.web provides a web based client and plugin infrastructure. There is currently no escaping or validation of the `callback` parameter that can be passed to various OMERO.web endpoints that have JSONP enabled. This vulnerability has been patched in version 5.26.0.

CVSS Score: 6.1 (MEDIUM)
CWE: CWE-830
References: https://github.com/ome/omero-web/commit/d41207cbb82afc56ea79e84db532608aa24ab4aa; https://github.com/ome/omero-web/security/advisories/GHSA-vr85-5pwx-c6gq; https://github.com/ome/omero-web/commit/d41207cbb82afc56ea79e84db532608aa24ab4aa
CVE: CVE-2024-35361
Published: 2024-05-21
Description: MTab Bookmark v1.9.5 has an SQL injection vulnerability in /LinkStore/getIcon. An attacker can execute arbitrary SQL statements through this vulnerability without requiring any user rights.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-89
References: https://github.com/Hebing123/cve/issues/37; https://github.com/Hebing123/cve/issues/37
CVE: CVE-2023-3943
Published: 2024-05-21
Description: Stack-based Buffer Overflow vulnerability in ZkTeco-based OEM devices allows, in some cases, the execution of arbitrary code. Due to the lack of protection mechanisms such as stack canaries and PIE, it is possible to successfully execute code even under restrictive conditions.

This issue affects 
ZkTeco-based OEM devices (ZkTeco ProFace X, Smartec ST-FR043, Smartec ST-FR041ME and possibly others)

 with firmware 
ZAM170-NF-1.8.25-7354-Ver1.0.0 and possibly others.
CVSS Score: 10.0 (CRITICAL)
CWE: CWE-121
References: https://github.com/klsecservices/Advisories/blob/master/K-ZkTeco-2023-006.md; https://github.com/klsecservices/Advisories/blob/master/K-ZkTeco-2023-006.md
CVE: CVE-2024-34071
Published: 2024-05-21
Description: Umbraco is an ASP.NET CMS used by more than 730.000 websites. Umbraco has an endpoint that is vulnerable to open redirects. The endpoint is protected so it requires the user to be signed into backoffice before the vulnerable is exposed. This vulnerability has been patched in version(s) 8.18.14, 10.8.6, 12.3.10 and 13.3.1.
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-601, CWE-601
References: https://github.com/umbraco/Umbraco-CMS/commit/5f24de308584b9771240a6db1a34630a5114c450; https://github.com/umbraco/Umbraco-CMS/commit/c17d4e1a600098ec524e4126f[PII_REDACTED]bc33f; https://github.com/umbraco/Umbraco-CMS/commit/c8f71af646171074c13e5c34f74312def4512031
CVE: CVE-2024-35218
Published: 2024-05-21
Description: Umbraco CMS is an ASP.NET CMS used by more than 730.000 websites. Stored Cross-site scripting (XSS) enable attackers that have access to backoffice to bring malicious content into a website or application. This vulnerability has been patched in version(s) 8.18.13, 10.8.4, 12.3.7, 13.1.1 by implementing IHtmlSanitizer.





CVSS Score: 4.2 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://github.com/umbraco/Umbraco-CMS/commit/1b712fe6ec52aa4e71b3acf63e393c8e6ab85385; https://github.com/umbraco/Umbraco-CMS/commit/a2684069b1e9976444f60b4b37a80be05b87f6b6; https://github.com/umbraco/Umbraco-CMS/commit/cbf9f9bcd199d7ca0412be3071d275556f10b7ba
CVE: CVE-2024-35384
Published: 2024-05-21
Description: An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_array_length function in the mjs.c file.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-20
References: https://github.com/cesanta/mjs/issues/287; https://github.com/cesanta/mjs/issues/287
CVE: CVE-2024-35385
Published: 2024-05-21
Description: An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_mk_ffi_sig function in the mjs.c file.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-125
References: https://github.com/cesanta/mjs/issues/288; https://github.com/cesanta/mjs/issues/288
CVE: CVE-2024-35386
Published: 2024-05-21
Description: An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_do_gc function in the mjs.c file.
CVSS Score: 7.5 (HIGH)
References: https://github.com/cesanta/mjs/issues/286; https://github.com/cesanta/mjs/issues/286
CVE: CVE-2024-4452
Published: 2024-05-21
Description: The ElementsKit Pro plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in versions up to, and including, 3.6.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVSS Score: 6.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://wpmet.com/plugin/elementskit/; https://www.wordfence.com/threat-intel/vulnerabilities/id/488ac848-786e-4100-a387-5a40e8fc4175?source=cve; https://wpmet.com/plugin/elementskit/
CVE: CVE-2020-36788
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: avoid a use-after-free when BO init fails

nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm_bo_init() invokes the provided
destructor which should de-initialize and free the memory.

Thus, when nouveau_bo_init() returns an error the gem object has already
been released and the memory freed by nouveau_bo_del_ttm().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/548f2ff8ea5e0ce767ae3418d1ec5308990be87d; https://git.kernel.org/stable/c/bcf34aa5082ee2343574bc3f4d1c126030913e54; https://git.kernel.org/stable/c/f86e19d918a85492ad1a01fcdc0ad5ecbdac6f96
CVE: CVE-2021-47220
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47221
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/slub: actually fix freelist pointer vs redzoning

It turns out that SLUB redzoning ("slub_debug=Z") checks from
s->object_size rather than from s->inuse (which is normally bumped to
make room for the freelist pointer), so a cache created with an object
size less than 24 would have the freelist pointer written beyond
s->object_size, causing the redzone to be corrupted by the freelist
pointer.  This was very visible with "slub_debug=ZF":

  BUG test (Tainted: G    B            ): Right Redzone overwritten
  -----------------------------------------------------------------------------

  INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb
  INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x[PII_REDACTED]000000 flags=0x[PII_REDACTED]000200
  INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620

  Redzone  (____ptrval____): bb bb bb bb bb bb bb bb               ........
  Object   (____ptrval____): 00 00 00 00 00 f6 f4 a5               ........
  Redzone  (____ptrval____): 40 1d e8 1a aa                        @....
  Padding  (____ptrval____): 00 00 00 00 00 00 00 00               ........

Adjust the offset to stay within s->object_size.

(Note that no caches of in this size range are known to exist in the
kernel currently.)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-763
References: https://git.kernel.org/stable/c/ce6e8bee7a3883e8008b30f5887dbb426aac6a35; https://git.kernel.org/stable/c/e41a49fadbc80b60b48d3c095d9e2ee7ef7c9a8e; https://git.kernel.org/stable/c/f6ed[PII_REDACTED]a13a5841b3af4dc32ed984a25f
CVE: CVE-2021-47222
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix vlan tunnel dst refcnt when egressing

The egress tunnel code uses dst_clone() and directly sets the result
which is wrong because the entry might have 0 refcnt or be already deleted,
causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]
when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and
checking if a reference was actually taken before setting the dst.

[1] dmesg WARN_ON log and following refcnt errors
 WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
 Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net
 CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G        W         5.13.0-rc3+ #360
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
 Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49
 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246
 RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
 RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffffffffa01902a0
 RBP: ffff8881040c6700 R08: [PII_REDACTED] R09: [PII_REDACTED]
 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff[PII_REDACTED]00
 R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
 FS:  [PII_REDACTED](0000) GS:ffff88822bf40000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 00007f42ba70f030 CR3: [PII_REDACTED] CR4:[PII_REDACTED]0006e0
 Call Trace:
  br_handle_vlan+0xbc/0xca [bridge]
  __br_forward+0x23/0x164 [bridge]
  deliver_clone+0x41/0x48 [bridge]
  br_handle_frame_finish+0x36f/0x3aa [bridge]
  ? skb_dst+0x2e/0x38 [bridge]
  ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]
  ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
  br_handle_frame+0x2c3/0x377 [bridge]
  ? __skb_pull+0x33/0x51
  ? vlan_do_receive+0x4f/0x36a
  ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
  __netif_receive_skb_core+0x539/0x7c6
  ? __list_del_entry_valid+0x16e/0x1c2
  __netif_receive_skb_list_core+0x6d/0xd6
  netif_receive_skb_list_internal+0x1d9/0x1fa
  gro_normal_list+0x22/0x3e
  dev_gro_receive+0x55b/0x600
  ? detach_buf_split+0x58/0x140
  napi_gro_receive+0x94/0x12e
  virtnet_poll+0x15d/0x315 [virtio_net]
  __napi_poll+0x2c/0x1c9
  net_rx_action+0xe6/0x1fb
  __do_softirq+0x115/0x2d8
  run_ksoftirqd+0x18/0x20
  smpboot_thread_fn+0x183/0x19c
  ? smpboot_unregister_percpu_thread+0x66/0x66
  kthread+0x10a/0x10f
  ? kthread_mod_delayed_work+0xb6/0xb6
  ret_from_fork+0x22/0x30
 ---[ end trace 49f61b07f775fd2b ]---
 dst_release: dst:00000000c02d677a refcnt:-1
 dst_release underflow
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/25053a8404ba17ca48f5553d487afc1882e9f56c; https://git.kernel.org/stable/c/42020f7f37a90d24b9551f5f7eba3f7c7c102968; https://git.kernel.org/stable/c/79855be6445b6592bddb7bd7167083ec8cdbd73f
CVE: CVE-2021-47223
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix vlan tunnel dst null pointer dereference

This patch fixes a tunnel_dst null pointer dereference due to lockless
access in the tunnel egress path. When deleting a vlan tunnel the
tunnel_dst pointer is set to NULL without waiting a grace period (i.e.
while it's still usable) and packets egressing are dereferencing it
without checking. Use READ/WRITE_ONCE to annotate the lockless use of
tunnel_id, use RCU for accessing tunnel_dst and make sure it is read
only once and checked in the egress path. The dst is already properly RCU
protected so we don't need to do anything fancy than to make sure
tunnel_id and tunnel_dst are read only once and checked in the egress path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24a6e55f17aa123bc1fc54b7d3c410b41bc16530; https://git.kernel.org/stable/c/58e2071742e38f29f051b709a5cca014ba51166f; https://git.kernel.org/stable/c/a2241e62f6b4a774d8a92048fdf59c45f6c2fe5c
CVE: CVE-2021-47224
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ll_temac: Make sure to free skb when it is completely used

With the skb pointer piggy-backed on the TX BD, we have a simple and
efficient way to free the skb buffer when the frame has been transmitted.
But in order to avoid freeing the skb while there are still fragments from
the skb in use, we need to piggy-back on the TX BD of the skb, not the
first.

Without this, we are doing use-after-free on the DMA side, when the first
BD of a multi TX BD packet is seen as completed in xmit_done, and the
remaining BDs are still being processed.
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/019ab7d044d0ebf97e1236bb8935b7809be92358; https://git.kernel.org/stable/c/6aa32217a9a446275440ee8724b1ecaf1838df47; https://git.kernel.org/stable/c/6d120ab4dc39a543c6b63361e1d0541c382900a3
CVE: CVE-2021-47225
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix deadlock in AP/VLAN handling

Syzbot reports that when you have AP_VLAN interfaces that are up
and close the AP interface they belong to, we get a deadlock. No
surprise - since we dev_close() them with the wiphy mutex held,
which goes back into the netdev notifier in cfg80211 and tries to
acquire the wiphy mutex there.

To fix this, we need to do two things:
 1) prevent changing iftype while AP_VLANs are up, we can't
    easily fix this case since cfg80211 already calls us with
    the wiphy mutex held, but change_interface() is relatively
    rare in drivers anyway, so changing iftype isn't used much
    (and userspace has to fall back to down/change/up anyway)
 2) pull the dev_close() loop over VLANs out of the wiphy mutex
    section in the normal stop case
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/8043903fcb72f545c52e3ec74d6fd82ef79ce7c5; https://git.kernel.org/stable/c/d5befb224edbe53056c2c18999d630dafb4a08b9; https://git.kernel.org/stable/c/8043903fcb72f545c52e3ec74d6fd82ef79ce7c5
CVE: CVE-2021-47226
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer

Both Intel and AMD consider it to be architecturally valid for XRSTOR to
fail with #PF but nonetheless change the register state.  The actual
conditions under which this might occur are unclear [1], but it seems
plausible that this might be triggered if one sibling thread unmaps a page
and invalidates the shared TLB while another sibling thread is executing
XRSTOR on the page in question.

__fpu__restore_sig() can execute XRSTOR while the hardware registers
are preserved on behalf of a different victim task (using the
fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but
modify the registers.

If this happens, then there is a window in which __fpu__restore_sig()
could schedule out and the victim task could schedule back in without
reloading its own FPU registers. This would result in part of the FPU
state that __fpu__restore_sig() was attempting to load leaking into the
victim task's user-visible state.

Invalidate preserved FPU registers on XRSTOR failure to prevent this
situation from corrupting any state.

[1] Frequent readers of the errata lists might imagine "complex
    microarchitectural conditions".
CVSS Score: 7.1 (HIGH)
CWE: CWE-203
References: https://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14; https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb[PII_REDACTED]9de0b6817; https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953a
CVE: CVE-2021-47227
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Prevent state corruption in __fpu__restore_sig()

The non-compacted slowpath uses __copy_from_user() and copies the entire
user buffer into the kernel buffer, verbatim.  This means that the kernel
buffer may now contain entirely invalid state on which XRSTOR will #GP.
validate_user_xstate_header() can detect some of that corruption, but that
leaves the onus on callers to clear the buffer.

Prior to XSAVES support, it was possible just to reinitialize the buffer,
completely, but with supervisor states that is not longer possible as the
buffer clearing code split got it backwards. Fixing that is possible but
not corrupting the state in the first place is more robust.

Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()
which validates the XSAVE header contents before copying the actual states
to the kernel. copy_user_to_xstate() was previously only called for
compacted-format kernel buffers, but it works for both compacted and
non-compacted forms.

Using it for the non-compacted form is slower because of multiple
__copy_from_user() operations, but that cost is less important than robust
code in an already slow path.

[ Changelog polished by Dave Hansen ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/076f732b16a5bf842686e1b43ab6021a2d98233e; https://git.kernel.org/stable/c/484cea4f362e1eeb5c869abbfb5f90eae6421b38; https://git.kernel.org/stable/c/ec25ea1f3f05d6f8ee51d1277efea986eafd4f2a
CVE: CVE-2021-47228
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/ioremap: Map EFI-reserved memory as encrypted for SEV

Some drivers require memory that is marked as EFI boot services
data. In order for this memory to not be re-used by the kernel
after ExitBootServices(), efi_mem_reserve() is used to preserve it
by inserting a new EFI memory descriptor and marking it with the
EFI_MEMORY_RUNTIME attribute.

Under SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to
be mapped encrypted by Linux, otherwise the kernel might crash at boot
like below:

  EFI Variables Facility v0.08 2004-May-17
  general protection fault, probably for non-canonical address 0x[PII_REDACTED]a868b2: 0000 [#1] SMP NOPTI
  CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:efi_mokvar_entry_next
  [...]
  Call Trace:
   efi_mokvar_sysfs_init
   ? efi_mokvar_table_init
   do_one_initcall
   ? __kmalloc
   kernel_init_freeable
   ? rest_init
   kernel_init
   ret_from_fork

Expand the __ioremap_check_other() function to additionally check for
this other type of boot data reserved at runtime and indicate that it
should be mapped encrypted for an SEV guest.

 [ bp: Massage commit message. ]
CVSS Score: 6.2 (MEDIUM)
References: https://git.kernel.org/stable/c/208bb686e7fa7fff16e8fa78ff0db34aa9acdbd7; https://git.kernel.org/stable/c/8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b; https://git.kernel.org/stable/c/b7a05aba39f733ec337c5b952e112dd2dc4fc404
CVE: CVE-2021-47229
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: aardvark: Fix kernel panic during PIO transfer

Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:

    SError Interrupt on CPU0, code 0xbf000002 -- SError
    Kernel panic - not syncing: Asynchronous SError Interrupt

To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.

If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.

In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.

Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/[PII_REDACTED]1243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.

After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1a1dbc[PII_REDACTED]fe8c5f195c17b341c8e82867; https://git.kernel.org/stable/c/3d213a4ddf49a860be6e795482c17f87e0c82b2a; https://git.kernel.org/stable/c/400e6b1860c8be61388d0b77814c53260f96e17a
CVE: CVE-2021-47231
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

can: mcba_usb: fix memory leak in mcba_usb

Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
Analyzer Tool. The problem was in unfreed usb_coherent.

In mcba_usb_start() 20 coherent buffers are allocated and there is
nothing, that frees them:

1) In callback function the urb is resubmitted and that's all
2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
   is not set (see mcba_usb_start) and this flag cannot be used with
   coherent buffers.

Fail log:
| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)

So, all allocated buffers should be freed with usb_free_coherent()
explicitly

NOTE:
The same pattern for allocating and freeing coherent buffers
is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/6bd3d80d1f019cefa7011056c54b323f1d8b8e83; https://git.kernel.org/stable/c/6f87c0e21ad20dd3d22108e33db1c552dfa352a0; https://git.kernel.org/stable/c/89df95ce32be204eef2e7d4b2f6fb552fb191a68
CVE: CVE-2021-47232
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

can: j1939: fix Use-after-Free, hold skb ref while in use

This patch fixes a Use-after-Free found by the syzbot.

The problem is that a skb is taken from the per-session skb queue,
without incrementing the ref count. This leads to a Use-after-Free if
the skb is taken concurrently from the session queue due to a CTS.
CVSS Score: 8.4 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1071065eeb33d32b7d98c2ce7591881ae7381705; https://git.kernel.org/stable/c/2030043e616cab40f510299f09b636285e0a3678; https://git.kernel.org/stable/c/22cba878abf646cd3a02ee7c8c2cef7afe66a256
CVE: CVE-2021-47233
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL

devm_gpiod_get_array_optional may return NULL if no GPIO was assigned.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/ba8a26a7ce8617f9f3d6230de34b2302df086b41; https://git.kernel.org/stable/c/cb2381cbecb81a8893b2d1e1af29bc2e5531df27; https://git.kernel.org/stable/c/dc68f0c9e4a001e02376fe87f4bdcacadb27e8a1
CVE: CVE-2021-47234
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()

Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix
some resource leaks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/6472955af5e88b5489b6d78316082ad56ea3e489; https://git.kernel.org/stable/c/9a[PII_REDACTED]d01aa2ec109da5f93b8d31dd425; https://git.kernel.org/stable/c/aaac9a1bd370338ce372669eb9a6059d16b929aa