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

usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()

  ...
  cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
  list_del_init(&priv_req->list);
  ...

'priv_req' actually free at cdns3_gadget_ep_free_request(). But
list_del_init() use priv_req->list after it.

[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4
[ 1542.642868][  T534]
[ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):
[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4
[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]
[ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4
[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8
[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368
[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28

Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this
problem.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9; https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16; https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3
CVE: CVE-2024-26751
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

ARM: ep93xx: Add terminator to gpiod_lookup_table

Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8; https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482; https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8
CVE: CVE-2024-26752
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

l2tp: pass correct message length to ip6_append_data

l2tp_ip6_sendmsg needs to avoid accounting for the transport header
twice when splicing more data into an already partially-occupied skbuff.

To manage this, we check whether the skbuff contains data using
skb_queue_empty when deciding how much data to append using
ip6_append_data.

However, the code which performed the calculation was incorrect:

     ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;

...due to C operator precedence, this ends up setting ulen to
transhdrlen for messages with a non-zero length, which results in
corrupted packets on the wire.

Add parentheses to correct the calculation in line with the original
intent.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-131
References: https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d; https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500; https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
CVE: CVE-2024-26753
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: virtio/akcipher - Fix stack overflow on memcpy

sizeof(struct virtio_crypto_akcipher_session_para) is less than
sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from
stack variable leads stack overflow. Clang reports this issue by
commands:
make -j CC=clang-14 mrproper >/dev/null 2>&1
make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1
make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/
  virtio_crypto_akcipher_algs.o
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86; https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47; https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63
CVE: CVE-2024-26754
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()

The gtp_net_ops pernet operations structure for the subsystem must be
registered before registering the generic netlink family.

Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:

general protection fault, probably for non-canonical address
0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000010-0x[PII_REDACTED]000017]
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
      df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
      3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
RSP: 0018:ffff[PII_REDACTED]20 EFLAGS: 00010202
RAX: dffffc[PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: ffff88800fcda588 R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4:[PII_REDACTED]750ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ? show_regs+0x90/0xa0
 ? die_addr+0x50/0xd0
 ? exc_general_protection+0x148/0x220
 ? asm_exc_general_protection+0x22/0x30
 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
 ? __alloc_skb+0x1dd/0x350
 ? __pfx___alloc_skb+0x10/0x10
 genl_dumpit+0x11d/0x230
 netlink_dump+0x5b9/0xce0
 ? lockdep_hardirqs_on_prepare+0x253/0x430
 ? __pfx_netlink_dump+0x10/0x10
 ? kasan_save_track+0x10/0x40
 ? __kasan_kmalloc+0x9b/0xa0
 ? genl_start+0x675/0x970
 __netlink_dump_start+0x6fc/0x9f0
 genl_family_rcv_msg_dumpit+0x1bb/0x2d0
 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
 ? genl_op_from_small+0x2a/0x440
 ? cap_capable+0x1d0/0x240
 ? __pfx_genl_start+0x10/0x10
 ? __pfx_genl_dumpit+0x10/0x10
 ? __pfx_genl_done+0x10/0x10
 ? security_capable+0x9d/0xe0
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-476
References: https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec; https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca; https://git.kernel.org/stable/c/3963f16cc7643b461271989b[PII_REDACTED]74ad2a
CVE: CVE-2024-26755
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

md: Don't suspend the array for interrupted reshape

md_start_sync() will suspend the array if there are spares that can be
added or removed from conf, however, if reshape is still in progress,
this won't happen at all or data will be corrupted(remove_and_add_spares
won't be called from md_choose_sync_action for reshape), hence there is
no need to suspend the array if reshape is not done yet.

Meanwhile, there is a potential deadlock for raid456:

1) reshape is interrupted;

2) set one of the disk WantReplacement, and add a new disk to the array,
   however, recovery won't start until the reshape is finished;

3) then issue an IO across reshpae position, this IO will wait for
   reshape to make progress;

4) continue to reshape, then md_start_sync() found there is a spare disk
   that can be added to conf, mddev_suspend() is called;

Step 4 and step 3 is waiting for each other, deadlock triggered. Noted
this problem is found by code review, and it's not reporduced yet.

Fix this porblem by don't suspend the array for interrupted reshape,
this is safe because conf won't be changed until reshape is done.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48; https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7; https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48
CVE: CVE-2024-26756
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

md: Don't register sync_thread for reshape directly

Currently, if reshape is interrupted, then reassemble the array will
register sync_thread directly from pers->run(), in this case
'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee
that md_do_sync() will be executed, hence stop_sync_thread() will hang
because 'MD_RECOVERY_RUNNING' can't be cleared.

Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,
however, following hang can still be triggered by dm-raid test
shell/lvconvert-raid-reshape.sh occasionally:

[root@fedora ~]# cat /proc/1982/stack
[<0>] stop_sync_thread+0x1ab/0x270 [md_mod]
[<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod]
[<0>] raid_presuspend+0x1e/0x70 [dm_raid]
[<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]
[<0>] __dm_destroy+0x2a5/0x310 [dm_mod]
[<0>] dm_destroy+0x16/0x30 [dm_mod]
[<0>] dev_remove+0x165/0x290 [dm_mod]
[<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod]
[<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod]
[<0>] vfs_ioctl+0x21/0x60
[<0>] __x64_sys_ioctl+0xb9/0xe0
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Meanwhile mddev->recovery is:
MD_RECOVERY_RUNNING |
MD_RECOVERY_INTR |
MD_RECOVERY_RESHAPE |
MD_RECOVERY_FROZEN

Fix this problem by remove the code to register sync_thread directly
from raid10 and raid5. And let md_check_recovery() to register
sync_thread.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417; https://git.kernel.org/stable/c/ad39c08186f8a0f[PII_REDACTED]36ba86731d6aafe; https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417
CVE: CVE-2024-26757
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore read-only array in md_check_recovery()

Usually if the array is not read-write, md_check_recovery() won't
register new sync_thread in the first place. And if the array is
read-write and sync_thread is registered, md_set_readonly() will
unregister sync_thread before setting the array read-only. md/raid
follow this behavior hence there is no problem.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:

1) array is read-only. dm-raid update super block:
rs_update_sbs
 ro = mddev->ro
 mddev->ro = 0
  -> set array read-write
 md_update_sb

2) register new sync thread concurrently.

3) dm-raid set array back to read-only:
rs_update_sbs
 mddev->ro = ro

4) stop the array:
raid_dtr
 md_stop
  stop_sync_thread
    set_bit(MD_RECOVERY_INTR, &mddev->recovery);
    md_wakeup_thread_directly(mddev->sync_thread);
    wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

5) sync thread done:
 md_do_sync
 set_bit(MD_RECOVERY_DONE, &mddev->recovery);
 md_wakeup_thread(mddev->thread);

6) daemon thread can't unregister sync thread:
 md_check_recovery
  if (!md_is_rdwr(mddev) &&
      !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
   return;
  -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;

The root cause is that dm-raid manipulate 'mddev->ro' by itself,
however, dm-raid really should stop sync thread before setting the
array read-only. Unfortunately, I need to read more code before I
can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix
the problem the easy way for now to prevent dm-raid regression.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-404
References: https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3; https://git.kernel.org/stable/c/55a48ad2db64737f7ffc[PII_REDACTED]cc6e4c513b; https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3
CVE: CVE-2024-26758
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore suspended array in md_check_recovery()

mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:

1) suspend the array:
raid_postsuspend
 mddev_suspend

2) stop the array:
raid_dtr
 md_stop
  __md_stop_writes
   stop_sync_thread
    set_bit(MD_RECOVERY_INTR, &mddev->recovery);
    md_wakeup_thread_directly(mddev->sync_thread);
    wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

3) sync thread done:
md_do_sync
 set_bit(MD_RECOVERY_DONE, &mddev->recovery);
 md_wakeup_thread(mddev->thread);

4) daemon thread can't unregister sync thread:
md_check_recovery
 if (mddev->suspended)
   return; -> return directly
 md_read_sync_thread
 clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
 -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;

This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757; https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0; https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757
CVE: CVE-2024-26760
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: pscsi: Fix bio_put() for error case

As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc
wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit()
and kfree(). That is not done properly for the error case, hitting WARN and
NULL pointer dereference in bio_free().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec; https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921; https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
CVE: CVE-2024-26761
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window

The Linux CXL subsystem is built on the assumption that HPA == SPA.
That is, the host physical address (HPA) the HDM decoder registers are
programmed with are system physical addresses (SPA).

During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1,
8.1.3.8) are checked if the memory is enabled and the CXL range is in
a HPA window that is described in a CFMWS structure of the CXL host
bridge (cxl-3.1, 9.18.1.3).

Now, if the HPA is not an SPA, the CXL range does not match a CFMWS
window and the CXL memory range will be disabled then. The HDM decoder
stops working which causes system memory being disabled and further a
system hang during HDM decoder initialization, typically when a CXL
enabled kernel boots.

Prevent a system hang and do not disable the HDM decoder if the
decoder's CXL range is not found in a CFMWS window.

Note the change only fixes a hardware hang, but does not implement
HPA/SPA translation. Support for this can be added in a follow on
patch series.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]90d7f0ab8c46db1afb3cf1e075fd29; https://git.kernel.org/stable/c/0cab[PII_REDACTED]91302cd2e440ef1d253031c221; https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69
CVE: CVE-2024-26762
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/pci: Skip to handle RAS errors if CXL.mem device is detached

The PCI AER model is an awkward fit for CXL error handling. While the
expectation is that a PCI device can escalate to link reset to recover
from an AER event, the same reset on CXL amounts to a surprise memory
hotplug of massive amounts of memory.

At present, the CXL error handler attempts some optimistic error
handling to unbind the device from the cxl_mem driver after reaping some
RAS register values. This results in a "hopeful" attempt to unplug the
memory, but there is no guarantee that will succeed.

A subsequent AER notification after the memdev unbind event can no
longer assume the registers are mapped. Check for memdev bind before
reaping status register values to avoid crashes of the form:

 BUG: unable to handle page fault for address: ffa00000195e9100
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 [...]
 RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core]
 [...]
 Call Trace:
  <TASK>
  ? __die+0x24/0x70
  ? page_fault_oops+0x82/0x160
  ? kernelmode_fixup_or_oops+0x84/0x110
  ? exc_page_fault+0x113/0x170
  ? asm_exc_page_fault+0x26/0x30
  ? __pfx_dpc_reset_link+0x10/0x10
  ? __cxl_handle_ras+0x30/0x110 [cxl_core]
  ? find_cxl_port+0x59/0x80 [cxl_core]
  cxl_handle_rp_ras+0xbc/0xd0 [cxl_core]
  cxl_error_detected+0x6c/0xf0 [cxl_core]
  report_error_detected+0xc7/0x1c0
  pci_walk_bus+0x73/0x90
  pcie_do_recovery+0x23f/0x330

Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might
need to be replaced with a new PCI_ERS_RESULT_PANIC.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/21e5e84f3f63fdf44e49642a6e45cd895e921a84; https://git.kernel.org/stable/c/eef5c7b28dbecd6b141987a96db6c54e49828102; https://git.kernel.org/stable/c/21e5e84f3f63fdf44e49642a6e45cd895e921a84
CVE: CVE-2024-26763
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

dm-crypt: don't modify the data when using authenticated encryption

It was said that authenticated encryption could produce invalid tag when
the data that is being encrypted is modified [1]. So, fix this problem by
copying the data into the clone bio first and then encrypt them inside the
clone bio.

This may reduce performance, but it is needed to prevent the user from
corrupting the device by writing data with O_DIRECT and modifying them at
the same time.

[1] https://lore.kernel.org/all/[PII_REDACTED]4723.GA35324@sol.localdomain/T/
CVSS Score: 7.1 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa; https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529; https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90
CVE: CVE-2024-26764
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:

WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
 kiocb_set_cancel_fn+0x9c/0xa8
 ffs_epfile_read_iter+0x144/0x1d0
 io_read+0x19c/0x498
 io_issue_sqe+0x118/0x27c
 io_submit_sqes+0x25c/0x5fc
 __arm64_sys_io_uring_enter+0x104/0xab0
 invoke_syscall+0x58/0x11c
 el0_svc_common+0xb4/0xf4
 do_el0_svc+0x2c/0xb0
 el0_svc+0x2c/0xa4
 el0t_64_sync_handler+0x68/0xb4
 el0t_64_sync+0x1a4/0x1a8

Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio.
CVSS Score: 3.3 (LOW)
References: https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487; https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6; https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f
CVE: CVE-2024-26765
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Disable IRQ before init_fn() for nonboot CPUs

Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to
silence such warnings (and also avoid potential errors due to unexpected
interrupts):

WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
pc[PII_REDACTED]8e3334 ra[PII_REDACTED]7bd56c tp[PII_REDACTED]39c000 sp[PII_REDACTED]39fdd0
a0 [PII_REDACTED] a1 [PII_REDACTED] a2[PII_REDACTED]02c040 a3 [PII_REDACTED]
a4 [PII_REDACTED] a5 [PII_REDACTED] a6 [PII_REDACTED] a7[PII_REDACTED]8e3f4c
t0 [PII_REDACTED] t[PII_REDACTED]c70968 t2 [PII_REDACTED] t3[PII_REDACTED]05e56e
t4[PII_REDACTED]0002e4 t5 [PII_REDACTED] t6 ffffffff80000000 t7 [PII_REDACTED]
t8 [PII_REDACTED] u0 [PII_REDACTED] s9 [PII_REDACTED] s0 [PII_REDACTED]
s[PII_REDACTED]356ac0 s2 [PII_REDACTED] s3 [PII_REDACTED] s4 [PII_REDACTED]
s5[PII_REDACTED]36f000 s6 7fffffffffffffff s7 [PII_REDACTED] s8[PII_REDACTED]ca55f8
   ra:[PII_REDACTED]7bd56c tlb_init+0x24c/0x528
  ERA:[PII_REDACTED]8e3334 rcu_cpu_starting+0x214/0x280
 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
 PRMD: 00000000 (PPLV0 -PIE -PWE)
 EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
 ECFG: 00071000 (LIE=12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
 PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
Stack : [PII_REDACTED] [PII_REDACTED][PII_REDACTED]b6[PII_REDACTED]10039c000
       [PII_REDACTED]39fa30 [PII_REDACTED][PII_REDACTED]39fa38[PII_REDACTED]19a140
        [PII_REDACTED] [PII_REDACTED][PII_REDACTED]39f950 [PII_REDACTED]
        [PII_REDACTED] cb0cb028ec7e52e[PII_REDACTED]b90000 [PII_REDACTED]
        [PII_REDACTED] [PII_REDACTED] ffffffff916d12f1 [PII_REDACTED]
        [PII_REDACTED] [PII_REDACTED][PII_REDACTED]b90000 [PII_REDACTED]
        [PII_REDACTED][PII_REDACTED]19a140 [PII_REDACTED] [PII_REDACTED]
        [PII_REDACTED] [PII_REDACTED] ffffffffffc681f2 [PII_REDACTED]
       [PII_REDACTED]ca55f8 [PII_REDACTED][PII_REDACTED]7a4828 00007ffff057ded8
       [PII_REDACTED]0000b0 [PII_REDACTED] [PII_REDACTED] [PII_REDACTED]
        ...
Call Trace:
[<[PII_REDACTED]7a4828>] show_stack+0x48/0x1a0
[<[PII_REDACTED]b61874>] dump_stack_lvl+0x84/0xcc
[<[PII_REDACTED]7f60ac>] __warn+0x8c/0x1e0
[<[PII_REDACTED]b0ab34>] report_bug+0x1b4/0x280
[<[PII_REDACTED]b63110>] do_bp+0x2d0/0x480
[<[PII_REDACTED]7a2e20>] handle_bp+0x120/0x1c0
[<[PII_REDACTED]8e3334>] rcu_cpu_starting+0x214/0x280
[<[PII_REDACTED]7bd568>] tlb_init+0x248/0x528
[<[PII_REDACTED]7a4c44>] per_cpu_trap_init+0x124/0x160
[<[PII_REDACTED]7a19f4>] cpu_probe+0x494/0xa00
[<[PII_REDACTED]7b551c>] start_secondary+0x3c/0xc0
[<[PII_REDACTED]b66134>] smpboot_entry+0x50/0x58
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a; https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f; https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53