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

NFS: Fix use-after-free in nfs4_init_client()

KASAN reports a use-after-free when attempting to mount two different
exports through two different NICs that belong to the same server.

Olga was able to hit this with kernels starting somewhere between 5.7
and 5.10, but I traced the patch that introduced the clear_bit() call to
4.13. So something must have changed in the refcounting of the clp
pointer to make this call to nfs_put_client() the very last one.
CVSS Score: 7.5 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3e3c7ebbfac152d08be75c92802a64a1f6471a15; https://git.kernel.org/stable/c/42c10b0db064e45f5c5ae7019bbf2168ffab766c; https://git.kernel.org/stable/c/476bdb04c501fc64bf3b8464ffddefc8dbe01577
CVE: CVE-2021-47260
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix a potential NULL dereference in nfs_get_client()

None of the callers are expecting NULL returns from nfs_get_client() so
this code will lead to an Oops.  It's better to return an error
pointer.  I expect that this is dead code so hopefully no one is
affected.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0057ecef9f324007c0ba5fcca4ddd131178ce78b; https://git.kernel.org/stable/c/09226e8303beeec10f2ff844d2e46d1371dc58e0; https://git.kernel.org/stable/c/279ad78a00f8b9c5ff24171a59297187a3bd44b7
CVE: CVE-2021-47261
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/mlx5: Fix initializing CQ fragments buffer

The function init_cq_frag_buf() can be called to initialize the current CQ
fragments buffer cq->buf, or the temporary cq->resize_buf that is filled
during CQ resize operation.

However, the offending commit started to use function get_cqe() for
getting the CQEs, the issue with this change is that get_cqe() always
returns CQEs from cq->buf, which leads us to initialize the wrong buffer,
and in case of enlarging the CQ we try to access elements beyond the size
of the current cq->buf and eventually hit a kernel panic.

 [exception RIP: init_cq_frag_buf+103]
  [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
  [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
  [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
  [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
  [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
  [ffff9f799ddcbec8] kthread at ffffffffa66c5da1
  [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd

Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
takes the correct source buffer as a parameter.
CVSS Score: 7.8 (HIGH)
CWE: CWE-706
References: https://git.kernel.org/stable/c/1ec2dcd680c71d0d36fa25638b327a468babd5c9; https://git.kernel.org/stable/c/2ba0aa2feebda680ecfc3c552e867cf4d1b05a3a; https://git.kernel.org/stable/c/3e670c54eda238cb8a1ea93538a79ae89285c1c4
CVE: CVE-2021-47262
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message

Use the __string() machinery provided by the tracing subystem to make a
copy of the string literals consumed by the "nested VM-Enter failed"
tracepoint.  A complete copy is necessary to ensure that the tracepoint
can't outlive the data/memory it consumes and deference stale memory.

Because the tracepoint itself is defined by kvm, if kvm-intel and/or
kvm-amd are built as modules, the memory holding the string literals
defined by the vendor modules will be freed when the module is unloaded,
whereas the tracepoint and its data in the ring buffer will live until
kvm is unloaded (or "indefinitely" if kvm is built-in).

This bug has existed since the tracepoint was added, but was recently
exposed by a new check in tracing to detect exactly this type of bug.

  fmt: '%s%s
  ' current_buffer: ' vmx_dirty_log_t-140127  [003] ....  kvm_nested_vmenter_failed: '
  WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0
  CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184
  Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014
  RIP: 0010:trace_check_vprintf+0x3be/0x3e0
  Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20
  RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282
  RAX: [PII_REDACTED] RBX: ffffa895cc37bd08 RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: 00000000ffffdfff RDI: ffff9766cfad74f8
  RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8
  R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffffffffc0a041d4
  R13: ffffffffc0f4dba8 R14: [PII_REDACTED] R15: ffff976409f2c000
  FS:  00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4:[PII_REDACTED]1726e0
  Call Trace:
   trace_event_printf+0x5e/0x80
   trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]
   print_trace_line+0x1dd/0x4e0
   s_show+0x45/0x150
   seq_read_iter+0x2d5/0x4c0
   seq_read+0x106/0x150
   vfs_read+0x98/0x180
   ksys_read+0x5f/0xe0
   do_syscall_64+0x40/0xb0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/796d3bd4ac9316e70c181189318cd2bd98af34bc; https://git.kernel.org/stable/c/9fb088ce13bc3c59a51260207b487db3e556f275; https://git.kernel.org/stable/c/d046f724bbd725a24007b7e52b2d[PII_REDACTED]88
CVE: CVE-2021-47263
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: wcd934x: Fix shift-out-of-bounds error

bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1)
which is not right, and this was caught by below usban check

UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/dbec64b11c65d74f31427e2b9d5746fbf17bf840; https://git.kernel.org/stable/c/dd55331d493b7ea75c5db1f24d6822946fde2862; https://git.kernel.org/stable/c/e0b518a2eb44d8a74c19e50f79a8ed393e96d634
CVE: CVE-2021-47264
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: core: Fix Null-point-dereference in fmt_single_name()

Check the return value of devm_kstrdup() in case of
Null-point-dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/047fd16015a[PII_REDACTED]0aa6ce71f68b2c23368; https://git.kernel.org/stable/c/0e2c9aeb00289f279b8181fbd4c20765127d8943; https://git.kernel.org/stable/c/41daf6ba594d55f201c50280ebcd430590441da1
CVE: CVE-2021-47265
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA: Verify port when creating flow rule

Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.

Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9[PII_REDACTED]0400 8b001c20 (f9403c1a)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2adcb4c5a52a2623cd2b43efa7041e74d19f3a5e; https://git.kernel.org/stable/c/8dc1b0e0ca204596c50bcd159ee069ae0f998176; https://git.kernel.org/stable/c/2adcb4c5a52a2623cd2b43efa7041e74d19f3a5e
CVE: CVE-2021-47266
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/ipoib: Fix warning caused by destroying non-initial netns

After the commit 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib
interfaces"), if the IPoIB device is moved to non-initial netns,
destroying that netns lets the device vanish instead of moving it back to
the initial netns, This is happening because default_device_exit() skips
the interfaces due to having rtnl_link_ops set.

Steps to reporoduce:
  ip netns add foo
  ip link set mlx5_ib0 netns foo
  ip netns delete foo

WARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50
Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT
nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d
 fuse
CPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S      W  5.13.0-rc1+ #1
Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016
Workqueue: netns cleanup_net
RIP: 0010:netdev_exit+0x3f/0x50
Code: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48
8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b
c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00
RSP: 0018:ffffb297079d7e08 EFLAGS: 00010206
RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX:[PII_REDACTED]10000d
RDX:[PII_REDACTED]10000e RSI:[PII_REDACTED]10000d RDI: ffff8eb440042c00
RBP: ffffb297079d7e48 R08: [PII_REDACTED] R09: ffffffff9fdeac00
R10: ffff8eb5003be000 R11: [PII_REDACTED] R12: ffffffffa1545620
R13: ffffffffa1545628 R14: [PII_REDACTED] R15: ffffffffa1543b20
FS:  [PII_REDACTED](0000) GS:ffff8ed37fa00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4:[PII_REDACTED]3706e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 ops_exit_list.isra.9+0x36/0x70
 cleanup_net+0x234/0x390
 process_one_work+0x1cb/0x360
 ? process_one_work+0x360/0x360
 worker_thread+0x30/0x370
 ? process_one_work+0x360/0x360
 kthread+0x116/0x130
 ? kthread_park+0x80/0x80
 ret_from_fork+0x22/0x30

To avoid the above warning and later on the kernel panic that could happen
on shutdown due to a NULL pointer dereference, make sure to set the
netns_refund flag that was introduced by commit 3a5ca857079e ("can: dev:
Move device back to init netns on owning netns delete") to properly
restore the IPoIB interfaces to the initial netns.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0a672f7d89db2da17ae02733ccc08458be72a6f8; https://git.kernel.org/stable/c/64f1fb6acc2ab95982fc4334f351d7576c26f313; https://git.kernel.org/stable/c/67cf4e447b5e5e9e94996cb6812ae2828e0e0e27
CVE: CVE-2021-47267
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: fix various gadget panics on 10gbps cabling

usb_assign_descriptors() is called with 5 parameters,
the last 4 of which are the usb_descriptor_header for:
  full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),
  high-speed (USB2.0 - 480Mbps),
  super-speed (USB3.0 - 5Gbps),
  super-speed-plus (USB3.1 - 10Gbps).

The differences between full/high/super-speed descriptors are usually
substantial (due to changes in the maximum usb block size from 64 to 512
to 1024 bytes and other differences in the specs), while the difference
between 5 and 10Gbps descriptors may be as little as nothing
(in many cases the same tuning is simply good enough).

However if a gadget driver calls usb_assign_descriptors() with
a NULL descriptor for super-speed-plus and is then used on a max 10gbps
configuration, the kernel will crash with a null pointer dereference,
when a 10gbps capable device port + cable + host port combination shows up.
(This wouldn't happen if the gadget max-speed was set to 5gbps, but
it of course defaults to the maximum, and there's no real reason to
artificially limit it)

The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,
if a 10gbps descriptor wasn't provided.

Obviously this won't fix the problem if the 5gbps descriptor is also
NULL, but such cases can't be so trivially solved (and any such gadgets
are unlikely to be used with USB3 ports any way).
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/032e288097a553db5653af552dd8035cd2a0ba96; https://git.kernel.org/stable/c/45f9a2fe737dc0a5df270787f2231aee8985cd59; https://git.kernel.org/stable/c/5ef23506695b01d5d56a13a092a97f2478069d75
CVE: CVE-2021-47269
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: ep0: fix NULL pointer exception

There is no validation of the index from dwc3_wIndex_to_dep() and we might
be referring a non-existing ep and trigger a NULL pointer exception. In
certain configurations we might use fewer eps and the index might wrongly
indicate a larger ep index than existing.

By adding this validation from the patch we can actually report a wrong
index back to the caller.

In our usecase we are using a composite device on an older kernel, but
upstream might use this fix also. Unfortunately, I cannot describe the
hardware for others to reproduce the issue as it is a proprietary
implementation.

[   82.958261] Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]0000a4
[   82.966891] Mem abort info:
[   82.969663]   ESR = 0x96000006
[   82.972703]   Exception class = DABT (current EL), IL = 32 bits
[   82.978603]   SET = 0, FnV = 0
[   82.981642]   EA = 0, S1PTW = 0
[   82.984765] Data abort info:
[   82.987631]   ISV = 0, ISS = 0x00000006
[   82.991449]   CM = 0, WnR = 0
[   82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
[   83.000999] [[PII_REDACTED]0000a4] pgd=[PII_REDACTED]aa5003, pud=[PII_REDACTED]aa5003, pmd=[PII_REDACTED]
[   83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[   83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x[PII_REDACTED]85154c)
[   83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
[   83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
[   83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
[   83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94

...

[   83.141788] Call trace:
[   83.144227]  dwc3_ep0_handle_feature+0x414/0x43c
[   83.148823]  dwc3_ep0_interrupt+0x3b4/0xc94
[   83.181546] ---[ end trace aac6b5267d84c32f ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/366369b89bedd59b1425386e8d4a18a466e420e4; https://git.kernel.org/stable/c/[PII_REDACTED]14895e2697c766fbe17be8d0e9b67a; https://git.kernel.org/stable/c/60156089f07e724e4dc8483702d5e1ede4522749
CVE: CVE-2021-47270
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: fix various gadgets null ptr deref on 10gbps cabling.

This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/10770d2ac0094b053c8897d96d7b2737cd72f7c5; https://git.kernel.org/stable/c/4b289a0f3033f465b4fd51ba995251a7867a2aa2; https://git.kernel.org/stable/c/8cd5f45c1b769e3e9e0f4325dd08b6c3749dc7ee
CVE: CVE-2021-47271
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler

Patch fixes the following critical issue caused by deadlock which has been
detected during testing NCM class:

smp: csd: Detected non-responsive CSD lock (#1) on CPU#0
smp:     csd: CSD lock (#1) unresponsive.
....
RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0
RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002
RAX: [PII_REDACTED] RBX: ffff9ee8116b4a68 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff9ee8116b4658
RBP: ffffbc494011cde0 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffff9ee8116b4670 R11: [PII_REDACTED] R12: ffff9ee8116b4658
R13: ffff9ee8116b4670 R14: [PII_REDACTED] R15: ffff9ee8116b4658
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4:[PII_REDACTED]1706e0
Call Trace:
 <IRQ>
 do_raw_spin_lock+0xc0/0xd0
 _raw_spin_lock_irqsave+0x95/0xa0
 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]
 usb_ep_queue+0x35/0x110
 eth_start_xmit+0x220/0x3d0 [u_ether]
 ncm_tx_timeout+0x34/0x40 [usb_f_ncm]
 ? ncm_free_inst+0x50/0x50 [usb_f_ncm]
 __hrtimer_run_queues+0xac/0x440
 hrtimer_run_softirq+0x8c/0xb0
 __do_softirq+0xcf/0x428
 asm_call_irq_on_stack+0x12/0x20
 </IRQ>
 do_softirq_own_stack+0x61/0x70
 irq_exit_rcu+0xc1/0xd0
 sysvec_apic_timer_interrupt+0x52/0xb0
 asm_sysvec_apic_timer_interrupt+0x12/0x20
RIP: 0010:do_raw_spin_trylock+0x18/0x40
RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246
RAX: [PII_REDACTED] RBX: ffff9ee8116b4658 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff9ee8116b4658
RBP: ffffbc494138bda8 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffff9ee8116b4670 R11: [PII_REDACTED] R12: ffff9ee8116b4658
R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000
 _raw_spin_lock+0x3d/0x70
 ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]
 cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]
 ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]
 ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]
 ? irq_thread+0xa0/0x1c0
 irq_thread_fn+0x28/0x60
 irq_thread+0x105/0x1c0
 ? __kthread_parkme+0x42/0x90
 ? irq_forced_thread_fn+0x90/0x90
 ? wake_threads_waitq+0x30/0x30
 ? irq_thread_check_affinity+0xe0/0xe0
 kthread+0x12a/0x160
 ? kthread_park+0x90/0x90
 ret_from_fork+0x22/0x30

The root cause of issue is spin_lock/spin_unlock instruction instead
spin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler
function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/a9aecef198faae3240921b707bc09b602e966fce; https://git.kernel.org/stable/c/ae746b6f4ce619cf4032fd798a232b010907a397; https://git.kernel.org/stable/c/a9aecef198faae3240921b707bc09b602e966fce
CVE: CVE-2021-47272
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL

There exists a possible scenario in which dwc3_gadget_init() can fail:
during during host -> peripheral mode switch in dwc3_set_mode(), and
a pending gadget driver fails to bind.  Then, if the DRD undergoes
another mode switch from peripheral->host the resulting
dwc3_gadget_exit() will attempt to reference an invalid and dangling
dwc->gadget pointer as well as call dma_free_coherent() on unmapped
DMA pointers.

The exact scenario can be reproduced as follows:
 - Start DWC3 in peripheral mode
 - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)
 - Run FunctionFS userspace application (open EPs, write descriptors, etc)
 - Bind gadget driver to DWC3's UDC
 - Switch DWC3 to host mode
   => dwc3_gadget_exit() is called. usb_del_gadget() will put the
	ConfigFS driver instance on the gadget_driver_pending_list
 - Stop FunctionFS application (closes the ep files)
 - Switch DWC3 to peripheral mode
   => dwc3_gadget_init() fails as usb_add_gadget() calls
	check_pending_gadget_drivers() and attempts to rebind the UDC
	to the ConfigFS gadget but fails with -19 (-ENODEV) because the
	FFS instance is not in FFS_ACTIVE state (userspace has not
	re-opened and written the descriptors yet, i.e. desc_ready!=0).
 - Switch DWC3 back to host mode
   => dwc3_gadget_exit() is called again, but this time dwc->gadget
	is invalid.

Although it can be argued that userspace should take responsibility
for ensuring that the FunctionFS application be ready prior to
allowing the composite driver bind to the UDC, failure to do so
should not result in a panic from the kernel driver.

Fix this by setting dwc->gadget to NULL in the failure path of
dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out
unless the gadget pointer is valid.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03715ea2e3dbbc56947137ce3b4ac18a726b2f87; https://git.kernel.org/stable/c/4aad390363d2b9b3e92428dd34d27bb7ea8f1ee8; https://git.kernel.org/stable/c/851dee5a5da56564a70290713aee665403bb0b24
CVE: CVE-2021-47273
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled

When only PHY1 is used (for example on Odroid-HC4), the regmap init code
uses the usb2 ports when doesn't initialize the PHY1 regmap entry.

This fixes:
Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
...
pc : regmap_update_bits_base+0x40/0xa0
lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8
...
Call trace:
regmap_update_bits_base+0x40/0xa0
dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8
dwc3_meson_g12a_usb2_init+0x7c/0xc8
dwc3_meson_g12a_usb_init+0x28/0x48
dwc3_meson_g12a_probe+0x298/0x540
platform_probe+0x70/0xe0
really_probe+0xf0/0x4d8
driver_probe_device+0xfc/0x168
...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4d2aa178d2ad2fb[PII_REDACTED]0dde13e9aa2376; https://git.kernel.org/stable/c/750a0d75564293be3ed50f13ef7f38ab75106421; https://git.kernel.org/stable/c/d8dd3754e707104a34f8ec595034d503ea8871a2
CVE: CVE-2021-47276
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Do not blindly read the ip address in ftrace_bug()

It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.

Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-706
References: https://git.kernel.org/stable/c/0bc62e398bbd9e600959e610def[PII_REDACTED]b28; https://git.kernel.org/stable/c/3e4ddeb68751fb4fb657199aed9cfd5d02796875; https://git.kernel.org/stable/c/4aedc2bc2b32c93555f47c95610efb89cc1ec09b