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

net: fec: don't save PTP state if PTP is unsupported

Some platforms (such as i.MX25 and i.MX27) do not support PTP, so on
these platforms fec_ptp_init() is not called and the related members
in fep are not initialized. However, fec_ptp_save_state() is called
unconditionally, which causes the kernel to panic. Therefore, add a
condition so that fec_ptp_save_state() is not called if PTP is not
supported.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3192e8d4a1ef9fc9bd7a59cdce51543367e5edd6; https://git.kernel.org/stable/c/6be063071a457767ee229db13f019c2ec03bfe44; https://git.kernel.org/stable/c/7745e14f4c036ce94a5eb05d06e49b0d84b306f9
CVE: CVE-2024-51132
Published: 2024-11-05
Description: An XML External Entity (XXE) vulnerability in HAPI FHIR before v6.4.0 allows attackers to access sensitive information or execute arbitrary code via supplying a crafted request containing malicious XML entities.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-611
References: https://github.com/JAckLosingHeart/CVE-2024-51132-POC; https://github.com/hapifhir/org.hl7.fhir.core
CVE: CVE-2024-51362
Published: 2024-11-05
Description: The LSC Smart Connect Indoor IP Camera V7.6.32 is vulnerable to an information disclosure issue where live camera footage can be accessed through the RTSP protocol on port 8554 without requiring authentication. This allows unauthorized users with network access to view the camera's feed, potentially compromising user privacy and security. No credentials or special permissions are required, and access can be gained remotely over the network.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-306
References: https://shinxyy.github.io/blogs/CVE_2024_51362.html
CVE: CVE-2024-9579
Published: 2024-11-05
Description: A potential vulnerability was discovered in certain Poly video conferencing devices. The firmware flaw does not properly sanitize user input. The exploitation of this vulnerability is dependent on a layered attack and cannot be exploited by itself.
CVSS Score: 7.5 (HIGH)
CWE: CWE-77, CWE-77
References: https://support.hp.com/us-en/document/ish_1[PII_REDACTED]6533-16/hpsbpy03900
CVE: CVE-2024-50098
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down

There is a history of deadlock if reboot is performed at the beginning
of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS
shutdown, and at that time the audio driver was waiting on
blk_mq_submit_bio() holding a mutex_lock while reading the fw binary.
After that, a deadlock issue occurred while audio driver shutdown was
waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set
SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down
after a UFS shutdown will return an error.

[   31.907781]I[0:      swapper/0:    0]        1        130705007      [PII_REDACTED]     [PII_REDACTED]4                0 D(   2) 3 ffffff882e208000 *             init [device_shutdown]
[   31.907793]I[0:      swapper/0:    0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49]
[   31.907806]I[0:      swapper/0:    0] Call trace:
[   31.907810]I[0:      swapper/0:    0]  __switch_to+0x174/0x338
[   31.907819]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc
[   31.907826]I[0:      swapper/0:    0]  schedule+0x7c/0xe8
[   31.907834]I[0:      swapper/0:    0]  schedule_preempt_disabled+0x24/0x40
[   31.907842]I[0:      swapper/0:    0]  __mutex_lock+0x408/0xdac
[   31.907849]I[0:      swapper/0:    0]  __mutex_lock_slowpath+0x14/0x24
[   31.907858]I[0:      swapper/0:    0]  mutex_lock+0x40/0xec
[   31.907866]I[0:      swapper/0:    0]  device_shutdown+0x108/0x280
[   31.907875]I[0:      swapper/0:    0]  kernel_restart+0x4c/0x11c
[   31.907883]I[0:      swapper/0:    0]  __arm64_sys_reboot+0x15c/0x280
[   31.907890]I[0:      swapper/0:    0]  invoke_syscall+0x70/0x158
[   31.907899]I[0:      swapper/0:    0]  el0_svc_common+0xb4/0xf4
[   31.907909]I[0:      swapper/0:    0]  do_el0_svc+0x2c/0xb0
[   31.907918]I[0:      swapper/0:    0]  el0_svc+0x34/0xe0
[   31.907928]I[0:      swapper/0:    0]  el0t_64_sync_handler+0x68/0xb4
[   31.907937]I[0:      swapper/0:    0]  el0t_64_sync+0x1a0/0x1a4

[   31.908774]I[0:      swapper/0:    0]       49                0         11960702     [PII_REDACTED]7                0 D(   2) 6 ffffff882e28cb00 *      kworker/6:0 [__bio_queue_enter]
[   31.908783]I[0:      swapper/0:    0] Call trace:
[   31.908788]I[0:      swapper/0:    0]  __switch_to+0x174/0x338
[   31.908796]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc
[   31.908803]I[0:      swapper/0:    0]  schedule+0x7c/0xe8
[   31.908811]I[0:      swapper/0:    0]  __bio_queue_enter+0xb8/0x178
[   31.908818]I[0:      swapper/0:    0]  blk_mq_submit_bio+0x194/0x67c
[   31.908827]I[0:      swapper/0:    0]  __submit_bio+0xb8/0x19c
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/19a198b67767d952c8f3d0cf24eb3100522a8223; https://git.kernel.org/stable/c/7774d23622416dbbbdb21bf342b3f0d92cf1dc0f; https://git.kernel.org/stable/c/7bd9af254275fad7071d85f04616560deb598d7d
CVE: CVE-2024-50100
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: dummy-hcd: Fix "task hung" problem

The syzbot fuzzer has been encountering "task hung" problems ever
since the dummy-hcd driver was changed to use hrtimers instead of
regular timers.  It turns out that the problems are caused by a subtle
difference between the timer_pending() and hrtimer_active() APIs.

The changeover blindly replaced the first by the second.  However,
timer_pending() returns True when the timer is queued but not when its
callback is running, whereas hrtimer_active() returns True when the
hrtimer is queued _or_ its callback is running.  This difference
occasionally caused dummy_urb_enqueue() to think that the callback
routine had not yet started when in fact it was almost finished.  As a
result the hrtimer was not restarted, which made it impossible for the
driver to dequeue later the URB that was just enqueued.  This caused
usb_kill_urb() to hang, and things got worse from there.

Since hrtimers have no API for telling when they are queued and the
callback isn't running, the driver must keep track of this for itself.
That's what this patch does, adding a new "timer_pending" flag and
setting or clearing it at the appropriate times.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5189df7b[PII_REDACTED]882c220d6aca4e64981348; https://git.kernel.org/stable/c/7d85884576a3be3616c260fc1fa862a59579d1ab; https://git.kernel.org/stable/c/cf7ee2291da551fc4b109fda1f6a332cb8212065
CVE: CVE-2024-50101
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices

Previously, the domain_context_clear() function incorrectly called
pci_for_each_dma_alias() to set up context entries for non-PCI devices.
This could lead to kernel hangs or other unexpected behavior.

Add a check to only call pci_for_each_dma_alias() for PCI devices. For
non-PCI devices, domain_context_clear_one() is called directly.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04d6826ba7ba[PII_REDACTED]6e96c90c6565169e1c; https://git.kernel.org/stable/c/0bd9a30c22afb5da203386b811ec31429d2caa78; https://git.kernel.org/stable/c/6e02a277f1db24fa039e23783c8921c7b0e5b1b3
CVE: CVE-2024-50102
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

x86: fix user address masking non-canonical speculation issue

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
accesses in kernel space.  And so using just the high bit to decide
whether an access is in user space or kernel space ends up with the good
old "leak speculative data" if you have the right gadget using the
result:

  CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“

Now, the kernel surrounds the access with a STAC/CLAC pair, and those
instructions end up serializing execution on older Zen architectures,
which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1].
That improves performance of STAC/CLAC a lot, but also means that the
speculation window is now open.

Note that this affects not just the new address masking, but also the
regular valid_user_address() check used by access_ok(), and the asm
version of the sign bit check in the get_user() helpers.

It does not affect put_user() or clear_user() variants, since there's no
speculative result to be used in a gadget for those operations.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-203, CWE-203
References: https://git.kernel.org/stable/c/[PII_REDACTED]77a345d4f50aae3c68e28b469f601e; https://git.kernel.org/stable/c/86e6b1547b3d013bc392adf775b[PII_REDACTED]3c2
CVE: CVE-2024-50103
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()

A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could
possibly return NULL pointer. NULL Pointer Dereference may be
triggerred without addtional check.
Add a NULL check for the returned pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/03c9c2c2d2d0fe203dfe8f56bedbcf04e303d7c4; https://git.kernel.org/stable/c/1e235d02d803660777ec911a2c467ae41f8539f5; https://git.kernel.org/stable/c/49da1463c9e3d2082276c3e0e2a8b65a88711cd2
CVE: CVE-2024-50105
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc

Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to
soundcards") moved the allocation of Soundwire stream runtime from the
Qualcomm Soundwire driver to each individual machine sound card driver,
except that it forgot to update SC7280 card.

Just like for other Qualcomm sound cards using Soundwire, the card
driver should allocate and release the runtime.  Otherwise sound
playback will result in a NULL pointer dereference or other effect of
uninitialized memory accesses (which was confirmed on SDM845 having
similar issue).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/176a41ebec42a921277cd34e8c0c2e776a9dd6c4; https://git.kernel.org/stable/c/db7e59e6a39a4d3d54ca8197c796557e6d480b0d
CVE: CVE-2024-50108
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too

Stuart Hayhurst has found that both at bootup and fullscreen VA-API video
is leading to black screens for around 1 second and kernel WARNING [1] traces
when calling dmub_psr_enable() with Parade 08-01 TCON.

These symptoms all go away with PSR-SU disabled for this TCON, so disable
it for now while DMUB traces [2] from the failure can be analyzed and the failure
state properly root caused.

(cherry picked from commit afb634a6823d8d9db23c5fb04f79c[PII_REDACTED]b)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5660bcc4dd[PII_REDACTED]77d5042f1c48cce2b443; https://git.kernel.org/stable/c/ba1959f71117b27f3099ee789e0815360b4081dd; https://git.kernel.org/stable/c/c79e0a18e4b301401bb745702830be9041cfbf04
CVE: CVE-2024-50109
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix null ptr dereference in raid10_size()

In raid10_run() if raid10_set_queue_limits() succeed, the return value
is set to zero, and if following procedures failed raid10_run() will
return zero while mddev->private is still NULL, causing null ptr
dereference in raid10_size().

Fix the problem by only overwrite the return value if
raid10_set_queue_limits() failed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/825711e00117fc686ab89ac36a9a7b252dc349c6; https://git.kernel.org/stable/c/b3054db2fd2d35f2eb3b4b5fb1407792f465391c
CVE: CVE-2024-50110
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: fix one more kernel-infoleak in algo dumping

During fuzz testing, the following issue was discovered:

BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30
 _copy_to_iter+0x598/0x2a30
 __skb_datagram_iter+0x168/0x1060
 skb_copy_datagram_iter+0x5b/0x220
 netlink_recvmsg+0x362/0x1700
 sock_recvmsg+0x2dc/0x390
 __sys_recvfrom+0x381/0x6d0
 __x64_sys_recvfrom+0x130/0x200
 x64_sys_call+0x32c8/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was stored to memory at:
 copy_to_user_state_extra+0xcc1/0x1e00
 dump_one_state+0x28c/0x5f0
 xfrm_state_walk+0x548/0x11e0
 xfrm_dump_sa+0x1e0/0x840
 netlink_dump+0x943/0x1c40
 __netlink_dump_start+0x746/0xdb0
 xfrm_user_rcv_msg+0x429/0xc00
 netlink_rcv_skb+0x613/0x780
 xfrm_netlink_rcv+0x77/0xc0
 netlink_unicast+0xe90/0x1280
 netlink_sendmsg+0x126d/0x1490
 __sock_sendmsg+0x332/0x3d0
 ____sys_sendmsg+0x863/0xc30
 ___sys_sendmsg+0x285/0x3e0
 __x64_sys_sendmsg+0x2d6/0x560
 x64_sys_call+0x1316/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was created at:
 __kmalloc+0x571/0xd30
 attach_auth+0x106/0x3e0
 xfrm_add_sa+0x2aa0/0x4230
 xfrm_user_rcv_msg+0x832/0xc00
 netlink_rcv_skb+0x613/0x780
 xfrm_netlink_rcv+0x77/0xc0
 netlink_unicast+0xe90/0x1280
 netlink_sendmsg+0x126d/0x1490
 __sock_sendmsg+0x332/0x3d0
 ____sys_sendmsg+0x863/0xc30
 ___sys_sendmsg+0x285/0x3e0
 __x64_sys_sendmsg+0x2d6/0x560
 x64_sys_call+0x1316/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Bytes 328-379 of 732 are uninitialized
Memory access of size 732 starts at ffff88800e18e000
Data copied to user address 00007ff30f48aff0

CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014

Fixes copying of xfrm algorithms where some random
data of the structure fields can end up in userspace.
Padding in structures may be filled with random (possibly sensitve)
data and should never be given directly to user-space.

A similar issue was resolved in the commit
8222d5910dae ("xfrm: Zero padding when dumping algos and encap")

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/1e8fbd2441cb2ea28d6825f2985bf7d84af060bb; https://git.kernel.org/stable/c/610d4cea9b442b22b4820695fc3335e64849725e; https://git.kernel.org/stable/c/6889cd2a93e1e3606b3f6e958aa0924e836de4d2
CVE: CVE-2024-50111
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context

Unaligned access exception can be triggered in irq-enabled context such
as user mode, in this case do_ale() may call get_user() which may cause
sleep. Then we will get:

 BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7
 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe
 preempt_count: 0, expected: 0
 RCU nest depth: 0, expected: 0
 CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G        W          6.12.0-rc1+ #1723
 Tainted: [W]=WARN
 Stack :[PII_REDACTED]e0bd48 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]e08000
        [PII_REDACTED]e0bc70[PII_REDACTED]e0bc78 [PII_REDACTED] [PII_REDACTED]
        [PII_REDACTED]e0bc78 [PII_REDACTED][PII_REDACTED]e0ba07[PII_REDACTED]e0b890
         ffffffffffffffff[PII_REDACTED]e0bc78 73924b81763be05b [PII_REDACTED]
        [PII_REDACTED]00020c[PII_REDACTED]00000a [PII_REDACTED] [PII_REDACTED]
        [PII_REDACTED]0023f0[PII_REDACTED]0e[PII_REDACTED]0072f8[PII_REDACTED]ffbb0e260
         [PII_REDACTED] [PII_REDACTED] [PII_REDACTED][PII_REDACTED]5d5000
         [PII_REDACTED] [PII_REDACTED] 0000007ffbb0e1f0 [PII_REDACTED]
        [PII_REDACTED]b00490 [PII_REDACTED] [PII_REDACTED] 0000007ffbb0dfec
        [PII_REDACTED]0000b0 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]071c1d
         ...
 Call Trace:
 [<[PII_REDACTED]>] show_stack+0x64/0x1a0
 [<[PII_REDACTED]c57464>] dump_stack_lvl+0x74/0xb0
 [<[PII_REDACTED]861ab4>] __might_resched+0x154/0x1a0
 [<[PII_REDACTED]80c96c>] emulate_load_store_insn+0x6c/0xf60
 [<[PII_REDACTED]c58118>] do_ale+0x78/0x180
 [<[PII_REDACTED]801bc8>] handle_ale+0x128/0x1e0

So enable IRQ if unaligned access exception is triggered in irq-enabled
context to fix it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/69cc6fad5df4ce652d969be69acc60e269e5eea1; https://git.kernel.org/stable/c/8915ed160dbd32b5ef5864df9a9fc11db83a77bb; https://git.kernel.org/stable/c/afbfb3568d78082078acc8bb2b29bb47af87253c
CVE: CVE-2024-50112
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/lam: Disable ADDRESS_MASKING in most cases

Linear Address Masking (LAM) has a weakness related to transient
execution as described in the SLAM paper[1]. Unless Linear Address
Space Separation (LASS) is enabled this weakness may be exploitable.

Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST,
or when speculation mitigations have been disabled at compile time,
otherwise keep LAM disabled.

There are no processors in market that support LAM yet, so currently
nobody is affected by this issue.

[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf
[2] LASS: https://lore.kernel.org/lkml/[PII_REDACTED]3632.48706-1-alexander.shishkin@linux.intel.com/

[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ]
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/3267cb6d3a174ff83d6287dcd5b0047bbd912452; https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f; https://git.kernel.org/stable/c/[PII_REDACTED]88d16db96ac0d6340f9372fc56f337
CVE: CVE-2024-50113
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

firewire: core: fix invalid port index for parent device

In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self
ID sequence"), the enumeration over self ID sequence was refactored with
some helper functions with KUnit tests. These helper functions are
guaranteed to work expectedly by the KUnit tests, however their application
includes a mistake to assign invalid value to the index of port connected
to parent device.

This bug affects the case that any extra node devices which has three or
more ports are connected to 1394 OHCI controller. In the case, the path
to update the tree cache could hits WARN_ON(), and gets general protection
fault due to the access to invalid address computed by the invalid value.

This commit fixes the bug to assign correct port index.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/90753a38bc3d058820981f812a908a99f7b337c1; https://git.kernel.org/stable/c/f6a6780e0b9bbcf311a727afed06fee533a5e957
CVE: CVE-2024-50114
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Unregister redistributor for failed vCPU creation

Alex reports that syzkaller has managed to trigger a use-after-free when
tearing down a VM:

  BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769
  Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758

  CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317
   show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324
   __dump_stack lib/dump_stack.c:93 [inline]
   dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119
   print_report+0x144/0x7a4 mm/kasan/report.c:377
   kasan_report+0xcc/0x128 mm/kasan/report.c:601
   __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
   kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769
   kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409
   __fput+0x198/0x71c fs/file_table.c:422
   ____fput+0x20/0x30 fs/file_table.c:450
   task_work_run+0x1cc/0x23c kernel/task_work.c:228
   do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50
   el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169
   el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Upon closer inspection, it appears that we do not properly tear down the
MMIO registration for a vCPU that fails creation late in the game, e.g.
a vCPU w/ the same ID already exists in the VM.

It is important to consider the context of commit that introduced this bug
by moving the unregistration out of __kvm_vgic_vcpu_destroy(). That
change correctly sought to avoid an srcu v. config_lock inversion by
breaking up the vCPU teardown into two parts, one guarded by the
config_lock.

Fix the use-after-free while avoiding lock inversion by adding a
special-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safe
because failed vCPUs are torn down outside of the config_lock.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/6bcc2890b883ba1d16b[PII_REDACTED]565f6e9db0d; https://git.kernel.org/stable/c/ae8f8b[PII_REDACTED]9326f4318df161206c59843e
CVE: CVE-2024-50115
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory

Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.

In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.

Per the APM:

  The CR3 register points to the base address of the page-directory-pointer
  table. The page-directory-pointer table is aligned on a 32-byte boundary,
  with the low 5 address bits 4:0 assumed to be 0.

And the SDM's much more explicit:

  4:0    Ignored

Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/2c4adc9b192a0815fe58a62bc[PII_REDACTED]cc884; https://git.kernel.org/stable/c/426682afec71ea3f889b972d038238807b9443e4; https://git.kernel.org/stable/c/58cb697d80e669c56197f703e188867c8c54c494
CVE: CVE-2024-50116
Published: 2024-11-05
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix kernel bug due to missing clearing of buffer delay flag

Syzbot reported that after nilfs2 reads a corrupted file system image
and degrades to read-only, the BUG_ON check for the buffer delay flag
in submit_bh_wbc() may fail, causing a kernel bug.

This is because the buffer delay flag is not cleared when clearing the
buffer state flags to discard a page/folio or a buffer head. So, fix
this.

This became necessary when the use of nilfs2's own page clear routine
was expanded.  This state inconsistency does not occur if the buffer
is written normally by log writing.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/033bc52f35868c2493a2d95c56ece7fc155d7cb3; https://git.kernel.org/stable/c/27524f65621f490184f2ace44cd8e5f3685af4a3; https://git.kernel.org/stable/c/412a30b1b28d6073ba29c46a2b0f324c5936293f