deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-45170
Published: 2024-09-04
Description: An issue was discovered in za-internet C-MOR Video Surveillance 5.2401. Due to improper or missing access control, low privileged users can use administrative functions of the C-MOR web interface. It was found out that different functions are only available to administrative users. However, access those functions is restricted via the web application user interface and not checked on the server side. Thus, by sending corresponding HTTP requests to the web server of the C-MOR web interface, low privileged users can also use administrative functionality, for instance downloading backup files or changing configuration settings.
CVSS Score: 8.1 (HIGH)
CWE: CWE-284
References: https://www-syss-de.translate.goog/pentest-blog/mehrere-sicherheitsschwachstellen-in-videoueberwachungssoftware-c-mor-syss-2024-020-bis-030?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp; https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-024.txt; http://seclists.org/fulldisclosure/2024/Sep/12
CVE: CVE-2024-45174
Published: 2024-09-04
Description: An issue was discovered in za-internet C-MOR Video Surveillance 5.2401 and 6.00PL01. Due to improper validation of user-supplied data, different functionalities of the C-MOR web interface are vulnerable to SQL injection attacks. This kind of attack allows an authenticated user to execute arbitrary SQL commands in the context of the corresponding MySQL database.
CVSS Score: 8.1 (HIGH)
CWE: CWE-89
References: https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-023.txt; https://www.syss.de/pentest-blog/mehrere-sicherheitsschwachstellen-in-videoueberwachungssoftware-c-mor-syss-2024-020-bis-030; http://seclists.org/fulldisclosure/2024/Sep/11
CVE: CVE-2024-8414
Published: 2024-09-04
Description: A vulnerability has been found in SourceCodester Insurance Management System 1.0 and classified as problematic. Affected by this vulnerability is an unknown functionality. The manipulation leads to cross-site request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-352, CWE-352
References: https://drive.google.com/file/d/1LMkTt5gbVXnRB9m9o2MdgB1S0fsSAvGL/view; https://vuldb.com/?ctiid.276493; https://vuldb.com/?id.276493
CVE: CVE-2024-8415
Published: 2024-09-04
Description: A vulnerability was found in SourceCodester Food Ordering Management System 1.0 and classified as critical. Affected by this issue is some unknown functionality of the file /routers/add-ticket.php. The manipulation of the argument id leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-89
References: https://github.com/Niu-zida/cve/blob/main/sql.md; https://vuldb.com/?ctiid.276494; https://vuldb.com/?id.276494
CVE: CVE-2024-45177
Published: 2024-09-04
Description: An issue was discovered in za-internet C-MOR Video Surveillance 5.2401 and 6.00PL01. Due to improper input validation, the C-MOR web interface is vulnerable to persistent cross-site scripting (XSS) attacks. It was found out that the camera configuration is vulnerable to a persistent cross-site scripting attack due to insufficient user input validation.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-021.txt; https://www.syss.de/pentest-blog/mehrere-sicherheitsschwachstellen-in-videoueberwachungssoftware-c-mor-syss-2024-020-bis-030; http://seclists.org/fulldisclosure/2024/Sep/9
CVE: CVE-2024-8416
Published: 2024-09-04
Description: A vulnerability was found in SourceCodester Food Ordering Management System 1.0. It has been classified as critical. This affects an unknown part of the file /routers/ticket-status.php. The manipulation of the argument ticket_id leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-89
References: https://github.com/SherlockMA0/cve/blob/main/sql2.md; https://vuldb.com/?ctiid.276495; https://vuldb.com/?id.276495
CVE: CVE-2024-8417
Published: 2024-09-04
Description: A vulnerability was found in 云课网络科技有限公司 Yunke Online School System up to 1.5.5. It has been declared as problematic. This vulnerability affects unknown code of the file /admin/educloud/videobind.html. The manipulation leads to inclusion of sensitive information in source code. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.5.6 is able to address this issue. It is recommended to upgrade the affected component.
CVSS Score: 3.1 (LOW)
CWE: CWE-540
References: https://vuldb.com/?ctiid.276496; https://vuldb.com/?id.276496; https://vuldb.com/?submit.402376
CVE: CVE-2024-44948
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/mtrr: Check if fixed MTRRs exist before saving them

MTRRs have an obsolete fixed variant for fine grained caching control
of the 640K-1MB region that uses separate MSRs. This fixed variant has
a separate capability bit in the MTRR capability MSR.

So far all x86 CPUs which support MTRR have this separate bit set, so it
went unnoticed that mtrr_save_state() does not check the capability bit
before accessing the fixed MTRR MSRs.

Though on a CPU that does not support the fixed MTRR capability this
results in a #GP.  The #GP itself is harmless because the RDMSR fault is
handled gracefully, but results in a WARN_ON().

Add the missing capability check to prevent this.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/06c1de44d378ec5439db17bf476507d68589bfe9; https://git.kernel.org/stable/c/34f36e6ee5bd7eff8b2adcd9fcaef369f752d82e; https://git.kernel.org/stable/c/388f1c954019f253a8383f7eb733f38d541e10b6
CVE: CVE-2024-44949
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: fix a possible DMA corruption

ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.

This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that's the largest possible cache line size.

As different parisc microarchitectures have different cache line size, we
define arch_slab_minalign(), cache_line_size() and
dma_get_cache_alignment() so that the kernel may tune slab cache
parameters dynamically, based on the detected cache line size.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/00baca74fb5879e5f9034b[PII_REDACTED]f500f8ee; https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f; https://git.kernel.org/stable/c/642a0b7453daff[PII_REDACTED]016fcb56d1f5bc7f
CVE: CVE-2024-44950
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: sc16is7xx: fix invalid FIFO access with special register set

When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.

Call graph example:
    sc16is7xx_startup(): entry
    sc16is7xx_ms_proc(): entry
    sc16is7xx_set_termios(): entry
    sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set
    sc16is7xx_port_irq() entry            --> IIR is 0x0C
    sc16is7xx_handle_rx() entry
    sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is
                               mapped to DLL (LCR=LCR_CONF_MODE_A)
    sc16is7xx_set_baud(): exit --> Restore access to general register set

Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6a[PII_REDACTED]a9a5ce4003eb347da1ee5abd06b0; https://git.kernel.org/stable/c/7d3b793faaab1305994ce568b59d61927235f57b; https://git.kernel.org/stable/c/cc6a3f35bc9b3a8da1b195420a2e8d9fdadfa831
CVE: CVE-2024-44951
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: sc16is7xx: fix TX fifo corruption

Sometimes, when a packet is received on channel A at almost the same time
as a packet is about to be transmitted on channel B, we observe with a
logic analyzer that the received packet on channel A is transmitted on
channel B. In other words, the Tx buffer data on channel B is corrupted
with data from channel A.

The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change
EFR lock to operate on each channels"), which changed the EFR locking to
operate on each channel instead of chip-wise.

This commit has introduced a regression, because the EFR lock is used not
only to protect the EFR registers access, but also, in a very obscure and
undocumented way, to protect access to the data buffer, which is shared by
the Tx and Rx handlers, but also by each channel of the IC.

Fix this regression first by switching to kfifo_out_linear_ptr() in
sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.

Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for
each channel.
CVSS Score: 7.8 (HIGH)
CWE: CWE-667
References: https://git.kernel.org/stable/c/09cfe05e9907f3276887a20e267cc40e202f4fdd; https://git.kernel.org/stable/c/133f4c00b8b2bfcacead9b81e7e8edfceb4b06c4
CVE: CVE-2024-44952
Published: 2024-09-04
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-44953
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix deadlock during RTC update

There is a deadlock when runtime suspend waits for the flush of RTC work,
and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.

Here is deadlock backtrace:

kworker/0:1     D 4892.876354 10 10971 4859 0x4208060 0x8 10 0[PII_REDACTED]52367
ptr            f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff
<ffffffee5e71ddb0> __switch_to+0x1a8/0x2d4
<ffffffee5e71e604> __schedule+0x684/0xa98
<ffffffee5e71ea60> schedule+0x48/0xc8
<ffffffee5e725f78> schedule_timeout+0x48/0x170
<ffffffee5e71fb74> do_wait_for_common+0x108/0x1b0
<ffffffee5e71efe0> wait_for_completion+0x44/0x60
<ffffffee5d6de968> __flush_work+0x39c/0x424
<ffffffee5d6decc0> __cancel_work_sync+0xd8/0x208
<ffffffee5d6dee2c> cancel_delayed_work_sync+0x14/0x28
<ffffffee5e2551b8> __ufshcd_wl_suspend+0x19c/0x480
<ffffffee5e255fb8> ufshcd_wl_runtime_suspend+0x3c/0x1d4
<ffffffee5dffd80c> scsi_runtime_suspend+0x78/0xc8
<ffffffee5df93580> __rpm_callback+0x94/0x3e0
<ffffffee5df90b0c> rpm_suspend+0x2d4/0x65c
<ffffffee5df91448> __pm_runtime_suspend+0x80/0x114
<ffffffee5dffd95c> scsi_runtime_idle+0x38/0x6c
<ffffffee5df912f4> rpm_idle+0x264/0x338
<ffffffee5df90f14> __pm_runtime_idle+0x80/0x110
<ffffffee5e24ce44> ufshcd_rtc_work+0x128/0x1e4
<ffffffee5d6e3a40> process_one_work+0x26c/0x650
<ffffffee5d6e65c8> worker_thread+0x260/0x3d8
<ffffffee5d6edec8> kthread+0x110/0x134
<ffffffee5d616b18> ret_from_fork+0x10/0x20

Skip updating RTC if RPM state is not RPM_ACTIVE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3911af778f208e5f49d43ce739332b91e26bc48e; https://git.kernel.org/stable/c/a4921b76bc9421d3838e167f6a17ea3112d8fe62; https://git.kernel.org/stable/c/f13f1858a28c68b7fc0d72c2008d5c1f80d2e8d5
CVE: CVE-2024-44954
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB
completion callback and the rawmidi API access.  This could be a cause
of KMSAN warning triggered by syzkaller below (so put as reported-by
here).

This patch protects the midibuf call of the former code path with a
spinlock for avoiding the possible races.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1; https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5; https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a
CVE: CVE-2024-44955
Published: 2024-09-04
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-44956
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/preempt_fence: enlarge the fence critical section

It is really easy to introduce subtle deadlocks in
preempt_fence_work_func() since we operate on single global ordered-wq
for signalling our preempt fences behind the scenes, so even though we
signal a particular fence, everything in the callback should be in the
fence critical section, since blocking in the callback will prevent
other published fences from signalling. If we enlarge the fence critical
section to cover the entire callback, then lockdep should be able to
understand this better, and complain if we grab a sensitive lock like
vm->lock, which is also held when waiting on preempt fences.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294; https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd[PII_REDACTED]f
CVE: CVE-2024-44957
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

xen: privcmd: Switch from mutex to spinlock for irqfds

irqfd_wakeup() gets EPOLLHUP, when it is called by
eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which
gets called under spin_lock_irqsave(). We can't use a mutex here as it
will lead to a deadlock.

Fix it by switching over to a spin lock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3; https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae[PII_REDACTED]46e; https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c
CVE: CVE-2024-44958
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
 <TASK>
 __static_key_slow_dec_cpuslocked+0x16/0x70
 sched_cpu_deactivate+0x26e/0x2a0
 cpuhp_invoke_callback+0x3ad/0x10d0
 cpuhp_thread_fun+0x3f5/0x680
 smpboot_thread_fn+0x56d/0x8d0
 kthread+0x309/0x400
 ret_from_fork+0x41/0x70
 ret_from_fork_asm+0x1b/0x30
 </TASK>

Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2a3548c7ef2e135aee40e7e5e44e7d11b893e7c4; https://git.kernel.org/stable/c/2cf7665efe451e48d27953e6b5bc627d518c902b; https://git.kernel.org/stable/c/65727331b60197b742089855ac09464c22b96f66
CVE: CVE-2024-44960
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: core: Check for unset descriptor

Make sure the descriptor has been set before looking at maxpacket.
This fixes a null pointer panic in this case.

This may happen if the gadget doesn't properly set up the endpoint
for the current speed, or the gadget descriptors are malformed and
the descriptor for the speed/endpoint are not found.

No current gadget driver is known to have this problem, but this
may cause a hard-to-find bug during development of new gadgets.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1a9df57d57452b104c46c918569143cf21d7ebf1; https://git.kernel.org/stable/c/50c5248b0ea8aae0529fdf28dac42a41312d3b62; https://git.kernel.org/stable/c/716cba46f73a92645cf13eded8d257ed48afc2a4
CVE: CVE-2024-44961
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Forward soft recovery errors to userspace

As we discussed before[1], soft recovery should be
forwarded to userspace, or we can get into a really
bad state where apps will keep submitting hanging
command buffers cascading us to a hard reset.

1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/
(cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0da0b06165d83a8ecbb6582d9d5a135f9d38a52a; https://git.kernel.org/stable/c/829798c789f567ef6ba4b084c15b7b5f3bd98d51; https://git.kernel.org/stable/c/c28d207edfc5679585f4e96acb67000076ce90be
CVE: CVE-2024-44962
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading

When unload the btnxpuart driver, its associated timer will be deleted.
If the timer happens to be modified at this moment, it leads to the
kernel call this timer even after the driver unloaded, resulting in
kernel panic.
Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.

panic log:
  Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP
  Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic   snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil   snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded:   btnxpuart]
  CPU: 5 PID: 723 Comm: memtester Tainted: G           O       6.6.23-lts-next-06207-g4aef2658ac28 #1
  Hardware name: NXP i.MX95 19X19 board (DT)
  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : 0xffff80007a2cf464
  lr : call_timer_fn.isra.0+0x24/0x80
...
  Call trace:
   0xffff80007a2cf464
   __run_timers+0x234/0x280
   run_timer_softirq+0x20/0x40
   __do_softirq+0x100/0x26c
   ____do_softirq+0x10/0x1c
   call_on_irq_stack+0x24/0x4c
   do_softirq_own_stack+0x1c/0x2c
   irq_exit_rcu+0xc0/0xdc
   el0_interrupt+0x54/0xd8
   __el0_irq_handler_common+0x18/0x24
   el0t_64_irq_handler+0x10/0x1c
   el0t_64_irq+0x190/0x194
  Code: ???????? ???????? ???????? ???????? (????????)
  ---[ end trace [PII_REDACTED] ]---
  Kernel panic - not syncing: Oops: Fatal exception in interrupt
  SMP: stopping secondary CPUs
  Kernel Offset: disabled
  CPU features: 0x0,c0000000,40028143,1000721b
  Memory Limit: none
  ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d0df1e750bac0fdaa77940e711c1625cff08d33; https://git.kernel.org/stable/c/28bbb5011a[PII_REDACTED]da67bdb57ab6a914452b; https://git.kernel.org/stable/c/4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016
CVE: CVE-2024-44963
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not BUG_ON() when freeing tree block after error

When freeing a tree block, at btrfs_free_tree_block(), if we fail to
create a delayed reference we don't deal with the error and just do a
BUG_ON(). The error most likely to happen is -ENOMEM, and we have a
comment mentioning that only -ENOMEM can happen, but that is not true,
because in case qgroups are enabled any error returned from
btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned
from btrfs_search_slot() for example) can be propagated back to
btrfs_free_tree_block().

So stop doing a BUG_ON() and return the error to the callers and make
them abort the transaction to prevent leaking space. Syzbot was
triggering this, likely due to memory allocation failure injection.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/22d907bcd283d69d5e60497fc0d51969545c583b; https://git.kernel.org/stable/c/98251cd60b4d702a8a81de442ab621e83a3fb24f; https://git.kernel.org/stable/c/bb3868033a4cccff7be57e9145f2117cbdc91c11
CVE: CVE-2024-44964
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: fix memory leaks and crashes while performing a soft reset

The second tagged commit introduced a UAF, as it removed restoring
q_vector->vport pointers after reinitializating the structures.
This is due to that all queue allocation functions are performed here
with the new temporary vport structure and those functions rewrite
the backpointers to the vport. Then, this new struct is freed and
the pointers start leading to nowhere.

But generally speaking, the current logic is very fragile. It claims
to be more reliable when the system is low on memory, but in fact, it
consumes two times more memory as at the moment of running this
function, there are two vports allocated with their queues and vectors.
Moreover, it claims to prevent the driver from running into "bad state",
but in fact, any error during the rebuild leaves the old vport in the
partially allocated state.
Finally, if the interface is down when the function is called, it always
allocates a new queue set, but when the user decides to enable the
interface later on, vport_open() allocates them once again, IOW there's
a clear memory leak here.

Just don't allocate a new queue set when performing a reset, that solves
crashes and memory leaks. Readd the old queue number and reopen the
interface on rollback - that solves limbo states when the device is left
disabled and/or without HW queues enabled.
CVSS Score: 7.8 (HIGH)
CWE: CWE-401, CWE-416
References: https://git.kernel.org/stable/c/6b289f8d91537ec1e4f9c7b38b31b90d93b1419b; https://git.kernel.org/stable/c/f01032a2ca099ec8d619aaa916c3762aa62495df
CVE: CVE-2024-44965
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Fix pti_clone_pgtable() alignment assumption

Guenter reported dodgy crashes on an i386-nosmp build using GCC-11
that had the form of endless traps until entry stack exhaust and then
#DF from the stack guard.

It turned out that pti_clone_pgtable() had alignment assumptions on
the start address, notably it hard assumes start is PMD aligned. This
is true on x86_64, but very much not true on i386.

These assumptions can cause the end condition to malfunction, leading
to a 'short' clone. Guess what happens when the user mapping has a
short copy of the entry text?

Use the correct increment form for addr to avoid alignment
assumptions.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/18da1b27ce16a14a9b636af9232acb4fb24f4c9e; https://git.kernel.org/stable/c/25a727233a40a9b33370eec9f0cad67d8fd312f8; https://git.kernel.org/stable/c/41e71dbb0e0a0fe214545fe64af031303a08524c
CVE: CVE-2024-44966
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

binfmt_flat: Fix corruption when not offsetting data start

Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
introduced a RISC-V specific variant of the FLAT format which does
not allocate any space for the (obsolete) array of shared library
pointers. However, it did not disable the code which initializes the
array, resulting in the corruption of sizeof(long) bytes before the DATA
segment, generally the end of the TEXT segment.

Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of
the shared library pointer region so that it will only be initialized
if space is reserved for it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3a684499261d0f7ed5ee72793025c88c2276809c; https://git.kernel.org/stable/c/3eb3cd5992f7a0c37edc8d05b4c38c98758d8671; https://git.kernel.org/stable/c/49df34d2b7da9e57c839555a2f7877291ce45ad1