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

ipv6: fix possible UAF in ip6_finish_output2()

If skb_expand_head() returns NULL, skb has been freed
and associated dst/idev could also have been freed.

We need to hold rcu_read_lock() to make sure the dst and
associated idev are alive.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e; https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a; https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b
CVE: CVE-2024-44988
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: Fix out-of-bound access

If an ATU violation was caused by a CPU Load operation, the SPID could
be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/050e7274ab2150cd212b[PII_REDACTED]e7b83a15bd; https://git.kernel.org/stable/c/18b2e833daf049223ab3c2efdf8cdee08854c484; https://git.kernel.org/stable/c/4a88fca95c8df3746b71e31f44a02d35f06f9864
CVE: CVE-2024-44989
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

bonding: fix xfrm real_dev null pointer dereference

We shouldn't set real_dev to NULL because packets can be in transit and
xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume
real_dev is set.

 Example trace:
 kernel: BUG: unable to handle page fault for address: [PII_REDACTED]
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: #PF: supervisor write access in kernel mode
 kernel: #PF: error_code(0x0002) - not-present page
 kernel: PGD 0 P4D 0
 kernel: Oops: 0002 [#1] PREEMPT SMP
 kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12
 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:
 kernel: RAX: [PII_REDACTED] RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60
 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00
 kernel: RBP: ffff9eb3c0a42000 R08: [PII_REDACTED] R09: [PII_REDACTED]
 kernel: R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000
 kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:[PII_REDACTED]
 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 kernel: CR2: [PII_REDACTED] CR3:[PII_REDACTED]2ab000 CR4:[PII_REDACTED]350ef0
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: Call Trace:
 kernel:  <TASK>
 kernel:  ? __die+0x1f/0x60
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ? page_fault_oops+0x142/0x4c0
 kernel:  ? do_user_addr_fault+0x65/0x670
 kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel:  ? exc_page_fault+0x7b/0x180
 kernel:  ? asm_exc_page_fault+0x22/0x30
 kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]
 kernel:  xfrm_output+0x61/0x3b0
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ip_push_pending_frames+0x56/0x80
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/21816b696c172c19d53a30d45ee005cce246ed21; https://git.kernel.org/stable/c/2f72c6a66bcd7e0187ec085237fee5db27145294; https://git.kernel.org/stable/c/4582d4ff413a07d4ed8a4823c652dc[PII_REDACTED]
CVE: CVE-2024-44990
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

bonding: fix null pointer deref in bond_ipsec_offload_ok

We must check if there is an active slave before dereferencing the pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0707260a18312bbcd2a5668584e3692d0a29e3f6; https://git.kernel.org/stable/c/2f5bdd68c1ce64bda6bef4d361a3de23b04ccd59; https://git.kernel.org/stable/c/32a0173600c63aadaf2103bf02f074982e8602ab
CVE: CVE-2024-44991
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: prevent concurrent execution of tcp_sk_exit_batch

Its possible that two threads call tcp_sk_exit_batch() concurrently,
once from the cleanup_net workqueue, once from a task that failed to clone
a new netns.  In the latter case, error unwinding calls the exit handlers
in reverse order for the 'failed' netns.

tcp_sk_exit_batch() calls tcp_twsk_purge().
Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"),
this function picks up twsk in any dying netns, not just the one passed
in via exit_batch list.

This means that the error unwind of setup_net() can "steal" and destroy
timewait sockets belonging to the exiting netns.

This allows the netns exit worker to proceed to call

WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));

without the expected 1 -> 0 transition, which then splats.

At same time, error unwind path that is also running inet_twsk_purge()
will splat as well:

WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210
...
 refcount_dec include/linux/refcount.h:351 [inline]
 inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70
 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221
 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304
 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522
 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
 setup_net+0x714/0xb40 net/core/net_namespace.c:375
 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508
 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110

... because refcount_dec() of tw_refcount unexpectedly dropped to 0.

This doesn't seem like an actual bug (no tw sockets got lost and I don't
see a use-after-free) but as erroneous trigger of debug check.

Add a mutex to force strict ordering: the task that calls tcp_twsk_purge()
blocks other task from doing final _dec_and_test before mutex-owner has
removed all tw sockets of dying netns.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/565d121b69980637f040eb4d84289869cdaabedf; https://git.kernel.org/stable/c/99580ae890ec8bd98b21a2a9c6668f8f1555b62e; https://git.kernel.org/stable/c/e3d9de3742f4d5c47ae35f888d3023a5b54fcd2f
CVE: CVE-2024-44992
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

smb/client: avoid possible NULL dereference in cifs_free_subrequest()

Clang static checker (scan-build) warning:
	cifsglob.h:line 890, column 3
	Access to field 'ops' results in a dereference of a null pointer.

Commit 519be989717c ("cifs: Add a tracepoint to track credits involved in
R/W requests") adds a check for 'rdata->server', and let clang throw this
warning about NULL dereference.

When 'rdata->credits.value != 0 && rdata->server == NULL' happens,
add_credits_and_wake_if() will call rdata->server->ops->add_credits().
This will cause NULL dereference problem. Add a check for 'rdata->server'
to avoid NULL dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/74c2ab6d653b4c2354df65a7f7f2df1925a40a51; https://git.kernel.org/stable/c/fead60a6d5f84b472b928502a42c419253afe6c1
CVE: CVE-2024-44993
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`

When enabling UBSAN on Raspberry Pi 5, we get the following warning:

[  387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3
[  387.903868] index 7 is out of range for type '__u32 [7]'
[  387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G        WC         6.10.3-v8-16k-numa #151
[  387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[  387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched]
[  387.932525] Call trace:
[  387.935296]  dump_backtrace+0x170/0x1b8
[  387.939403]  show_stack+0x20/0x38
[  387.942907]  dump_stack_lvl+0x90/0xd0
[  387.946785]  dump_stack+0x18/0x28
[  387.950301]  __ubsan_handle_out_of_bounds+0x98/0xd0
[  387.955383]  v3d_csd_job_run+0x3a8/0x438 [v3d]
[  387.960707]  drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]
[  387.966862]  process_one_work+0x62c/0xb48
[  387.971296]  worker_thread+0x468/0x5b0
[  387.975317]  kthread+0x1c4/0x1e0
[  387.978818]  ret_from_fork+0x10/0x20
[  387.983014] ---[ end trace ]---

This happens because the UAPI provides only seven configuration
registers and we are reading the eighth position of this u32 array.

Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by
accessing only seven positions on the '__u32 [7]' array. The eighth
register exists indeed on V3D 7.1, but it isn't currently used. That
being so, let's guarantee that it remains unused and add a note that it
could be set in a future patch.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/497d370a644d95a9f04271aa92cb96d32e84c770; https://git.kernel.org/stable/c/d656b82c4b30cf12715e6cd129d3df808fde24a7
CVE: CVE-2024-44994
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu: Restore lost return in iommu_report_device_fault()

When iommu_report_device_fault gets called with a partial fault it is
supposed to collect the fault into the group and then return.

Instead the return was accidently deleted which results in trying to
process the fault and an eventual crash.

Deleting the return was a typo, put it back.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/cc6bc2ab1663ec[PII_REDACTED]af22452b078510e9; https://git.kernel.org/stable/c/fca5b78511e98bdff2cdd55c172b23200a7b3404
CVE: CVE-2024-44995
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is
as below:
                             pf reset start
                                 │
                                 ▼
                              ......
setup tc                         │
    │                            ▼
    ▼                      DOWN: napi_disable()
napi_disable()(skip)             │
    │                            │
    ▼                            ▼
  ......                      ......
    │                            │
    ▼                            │
napi_enable()                    │
                                 ▼
                           UINIT: netif_napi_del()
                                 │
                                 ▼
                              ......
                                 │
                                 ▼
                           INIT: netif_napi_add()
                                 │
                                 ▼
                              ......                 global reset start
                                 │                      │
                                 ▼                      ▼
                           UP: napi_enable()(skip)    ......
                                 │                      │
                                 ▼                      ▼
                              ......                 napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/[PII_REDACTED]8a6bb7f929d6a2ffffce9f1ece1cc; https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16; https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8
CVE: CVE-2024-44996
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock: fix recursive ->recvmsg calls

After a vsock socket has been added to a BPF sockmap, its prot->recvmsg
has been replaced with vsock_bpf_recvmsg(). Thus the following
recursiion could happen:

vsock_bpf_recvmsg()
 -> __vsock_recvmsg()
  -> vsock_connectible_recvmsg()
   -> prot->recvmsg()
    -> vsock_bpf_recvmsg() again

We need to fix it by calling the original ->recvmsg() without any BPF
sockmap logic in __vsock_recvmsg().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/69139d2919dd4aa9a553c8245e7c63e82613e3fc; https://git.kernel.org/stable/c/921f1acf0c3cf6b1260ab57a8a6e8b3d5f3023d5; https://git.kernel.org/stable/c/b4ee8cf1acc5018ed1369150d7bb3e0d0f79e135
CVE: CVE-2024-44997
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()

When there are multiple ap interfaces on one band and with WED on,
turning the interface down will cause a kernel panic on MT798X.

Previously, cb_priv was freed in mtk_wed_setup_tc_block() without
marking NULL,and mtk_wed_setup_tc_block_cb() didn't check the value, too.

Assign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL
in mtk_wed_setup_tc_block_cb().

----------
Unable to handle kernel paging request at virtual address 0072460bca32b4f5
Call trace:
 mtk_wed_setup_tc_block_cb+0x4/0x38
 0xffffffc0794084bc
 tcf_block_playback_offloads+0x70/0x1e8
 tcf_block_unbind+0x6c/0xc8
...
---------
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/326a89321f9d5fe399fe6f9ff7c0fc766582a6a0; https://git.kernel.org/stable/c/b453a4bbda03aa8741279c360ac82d1c3ac33548; https://git.kernel.org/stable/c/db1b4bedb9b97c6d34b03d03815147c04fffe8b4
CVE: CVE-2024-44998
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc->push() because the skb
is released.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/09e086a5f72ea27c758b3f3b419a69000c32adc1; https://git.kernel.org/stable/c/1cece837e387c039225f19028df255df87a97c0d; https://git.kernel.org/stable/c/24cf390a5426aac9255205e9533cdd7b4235d518
CVE: CVE-2024-45001
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix RX buf alloc_size alignment and atomic op panic

The MANA driver's RX buffer alloc_size is passed into napi_build_skb() to
create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment
is affected by the alloc_size passed into napi_build_skb(). The size needs
to be aligned properly for better performance and atomic operations.
Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic
operations may panic on the skb_shinfo(skb)->dataref due to alignment fault.

To fix this bug, add proper alignment to the alloc_size calculation.

Sample panic info:
[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce
[  253.300900] Mem abort info:
[  253.301760]   ESR = 0x[PII_REDACTED]000021
[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits
[  253.304268]   SET = 0, FnV = 0
[  253.305172]   EA = 0, S1PTW = 0
[  253.306103]   FSC = 0x21: alignment fault
Call trace:
 __skb_clone+0xfc/0x198
 skb_clone+0x78/0xe0
 raw6_local_deliver+0xfc/0x228
 ip6_protocol_deliver_rcu+0x80/0x500
 ip6_input_finish+0x48/0x80
 ip6_input+0x48/0xc0
 ip6_sublist_rcv_finish+0x50/0x78
 ip6_sublist_rcv+0x1cc/0x2b8
 ipv6_list_rcv+0x100/0x150
 __netif_receive_skb_list_core+0x180/0x220
 netif_receive_skb_list_internal+0x198/0x2a8
 __napi_poll+0x138/0x250
 net_rx_action+0x148/0x330
 handle_softirqs+0x12c/0x3a0
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/32316f676b4ee87c0404d333d248ccf777f739bc; https://git.kernel.org/stable/c/65f20b174ec0172f2d6bcfd8533ab9c9e7e347fa; https://git.kernel.org/stable/c/e6bea6a45f8a401f3d5a430bc81814f0cc8848cf
CVE: CVE-2024-45002
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

rtla/osnoise: Prevent NULL dereference in error handling

If the "tool->data" allocation fails then there is no need to call
osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/753f1745146e03abd17eec8eee95faffc96d743d; https://git.kernel.org/stable/c/90574d2a675947858b47008df8d07f75ea50d0d0; https://git.kernel.org/stable/c/abdb9ddaaab476e62805e36cce7b4ef8413ffd01
CVE: CVE-2024-45004
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: dcp: fix leak of blob encryption key

Trusted keys unseal the key blob on load, but keep the sealed payload in
the blob field so that every subsequent read (export) will simply
convert this field to hex and send it to userspace.

With DCP-based trusted keys, we decrypt the blob encryption key (BEK)
in the Kernel due hardware limitations and then decrypt the blob payload.
BEK decryption is done in-place which means that the trusted key blob
field is modified and it consequently holds the BEK in plain text.
Every subsequent read of that key thus send the plain text BEK instead
of the encrypted BEK to userspace.

This issue only occurs when importing a trusted DCP-based key and
then exporting it again. This should rarely happen as the common use cases
are to either create a new trusted key and export it, or import a key
blob and then just use it without exporting it again.

Fix this by performing BEK decryption and encryption in a dedicated
buffer. Further always wipe the plain text BEK buffer to prevent leaking
the key via uninitialized memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-312
References: https://git.kernel.org/stable/c/0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb; https://git.kernel.org/stable/c/9e3b266afcfe4294e84496f50f006f029d3100db
CVE: CVE-2024-45006
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command
can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size
value during enumeration. Usb core calls usb_ep0_reinit() in this case,
which ends up calling xhci_configure_endpoint().

On Panther point xHC the xhci_configure_endpoint() function will
additionally check and reserve bandwidth in software. Other hosts do
this in hardware

If xHC address device command fails then a new xhci_virt_device structure
is allocated as part of re-enabling the slot, but the bandwidth table
pointers are not set up properly here.
This triggers the NULL pointer dereference the next time usb_ep0_reinit()
is called and xhci_configure_endpoint() tries to check and reserve
bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[46710.713699] usb 3-1: Device not responding to setup address.
[46710.917684] usb 3-1: Device not responding to setup address.
[46711.125536] usb 3-1: device not accepting address 5, error -71
[46711.125594] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[46711.125600] #PF: supervisor read access in kernel mode
[46711.125603] #PF: error_code(0x0000) - not-present page
[46711.125606] PGD 0 P4D 0
[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI
[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1
[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.
[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]
[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly
after a failed address device command, and additionally by avoiding
checking for bandwidth in cases like this where no actual endpoints are
added or removed, i.e. only context for default control endpoint 0 is
evaluated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59; https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d; https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea
CVE: CVE-2024-45007
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

char: xillybus: Don't destroy workqueue from work item running on it

Triggered by a kref decrement, destroy_workqueue() may be called from
within a work item for destroying its own workqueue. This illegal
situation is averted by adding a module-global workqueue for exclusive
use of the offending work item. Other work items continue to be queued
on per-device workqueues to ensure performance.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9; https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3; https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157
CVE: CVE-2024-45008
Published: 2024-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05dd9aabd04f9b5eb04dab9bb83d8c3e982d7549; https://git.kernel.org/stable/c/2829c[PII_REDACTED]4456337e[PII_REDACTED]2785f3e; https://git.kernel.org/stable/c/87f610a1a7fbdb1f2e3d90b54c955bd3b8a0c322
CVE: CVE-2024-45172
Published: 2024-09-04
Description: An issue was discovered in za-internet C-MOR Video Surveillance 5.2401 and 6.00PL01. Due to missing protection mechanisms, the C-MOR web interface is vulnerable to cross-site request forgery (CSRF) attacks. The C-MOR web interface offers no protection against cross-site request forgery (CSRF) attacks.
CVSS Score: 6.8 (MEDIUM)
CWE: CWE-352
References: https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-022.txt; https://www.syss.de/pentest-blog/mehrere-sicherheitsschwachstellen-in-videoueberwachungssoftware-c-mor-syss-2024-020-bis-030; http://seclists.org/fulldisclosure/2024/Sep/10