Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachestat: fix page cache statistics permission checking<br /> <br /> When the &amp;#39;cachestat()&amp;#39; system call was added in commit cf264e1329fb<br /> ("cachestat: implement cachestat syscall"), it was meant to be a much<br /> more convenient (and performant) version of mincore() that didn&amp;#39;t need<br /> mapping things into the user virtual address space in order to work.<br /> <br /> But it ended up missing the "check for writability or ownership" fix for<br /> mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore()<br /> more conservative").<br /> <br /> This just adds equivalent logic to &amp;#39;cachestat()&amp;#39;, modified for the file<br /> context (rather than vma).

PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the pam_pkcs11 module segfaults when a user presses ctrl-c/ctrl-d when they are asked for a PIN. When a user enters no PIN at all, `pam_get_pwd` will never initialize the password buffer pointer and as such `cleanse` will try to dereference an uninitialized pointer. On my system this pointer happens to have the value 3 most of the time when running sudo and as such it will segfault. The most likely impact to a system affected by this issue is an availability impact due to a daemon that uses PAM crashing. As of time of publication, a patch for the issue is unavailable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: properly synchronize freeing resources during CPU hotunplug<br /> <br /> In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the<br /> current CPU at the beginning of the operation is retrieved and used<br /> throughout. However, since neither preemption nor migration are disabled,<br /> it is possible that the operation continues on a different CPU.<br /> <br /> If the original CPU is hotunplugged while the acomp_ctx is still in use,<br /> we run into a UAF bug as some of the resources attached to the acomp_ctx<br /> are freed during hotunplug in zswap_cpu_comp_dead() (i.e. <br /> acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).<br /> <br /> The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use<br /> crypto_acomp API for hardware acceleration") when the switch to the<br /> crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was<br /> retrieved using get_cpu_ptr() which disables preemption and makes sure the<br /> CPU cannot go away from under us. Preemption cannot be disabled with the<br /> crypto_acomp API as a sleepable context is needed.<br /> <br /> Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating<br /> and freeing resources with compression/decompression paths. Make sure<br /> that acomp_ctx.req is NULL when the resources are freed. In the<br /> compression/decompression paths, check if acomp_ctx.req is NULL after<br /> acquiring the mutex (meaning the CPU was offlined) and retry on the new<br /> CPU.<br /> <br /> The initialization of acomp_ctx.mutex is moved from the CPU hotplug<br /> callback to the pool initialization where it belongs (where the mutex is<br /> allocated). In addition to adding clarity, this makes sure that CPU<br /> hotplug cannot reinitialize a mutex that is already locked by<br /> compression/decompression.<br /> <br /> Previously a fix was attempted by holding cpus_read_lock() [1]. This<br /> would have caused a potential deadlock as it is possible for code already<br /> holding the lock to fall into reclaim and enter zswap (causing a<br /> deadlock). A fix was also attempted using SRCU for synchronization, but<br /> Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug<br /> notifiers [2].<br /> <br /> Alternative fixes that were considered/attempted and could have worked:<br /> - Refcounting the per-CPU acomp_ctx. This involves complexity in<br /> handling the race between the refcount dropping to zero in<br /> zswap_[de]compress() and the refcount being re-initialized when the<br /> CPU is onlined.<br /> - Disabling migration before getting the per-CPU acomp_ctx [3], but<br /> that&amp;#39;s discouraged and is a much bigger hammer than needed, and could<br /> result in subtle performance issues.<br /> <br /> [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/<br /> [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/<br /> [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/<br /> <br /> [yosryahmed@google.com: remove comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/platform: check the bounds of read/write syscalls<br /> <br /> count and offset are passed from user space and not checked, only<br /> offset is capped to 40 bits, which can be used to read/write out of<br /> bounds of the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Assign job pointer to NULL before signaling the fence<br /> <br /> In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL<br /> after job completion"), we introduced a change to assign the job pointer<br /> to NULL after completing a job, indicating job completion.<br /> <br /> However, this approach created a race condition between the DRM<br /> scheduler workqueue and the IRQ execution thread. As soon as the fence is<br /> signaled in the IRQ execution thread, a new job starts to be executed.<br /> This results in a race condition where the IRQ execution thread sets the<br /> job pointer to NULL simultaneously as the `run_job()` function assigns<br /> a new job to the pointer.<br /> <br /> This race condition can lead to a NULL pointer dereference if the IRQ<br /> execution thread sets the job pointer to NULL after `run_job()` assigns<br /> it to the new job. When the new job completes and the GPU emits an<br /> interrupt, `v3d_irq()` is triggered, potentially causing a crash.<br /> <br /> [ 466.310099] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0<br /> [ 466.318928] Mem abort info:<br /> [ 466.321723] ESR = 0x0000000096000005<br /> [ 466.325479] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 466.330807] SET = 0, FnV = 0<br /> [ 466.333864] EA = 0, S1PTW = 0<br /> [ 466.337010] FSC = 0x05: level 1 translation fault<br /> [ 466.341900] Data abort info:<br /> [ 466.344783] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 466.350285] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 466.355350] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 466.360677] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000089772000<br /> [ 466.367140] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 466.375875] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 466.382163] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc vc4 snd_soc_hdmi_codec drm_display_helper cec brcmfmac_wcc spidev rpivid_hevc(C) drm_client_lib brcmfmac hci_uart drm_dma_helper pisp_be btbcm brcmutil snd_soc_core aes_ce_blk v4l2_mem2mem bluetooth aes_ce_cipher snd_compress videobuf2_dma_contig ghash_ce cfg80211 gf128mul snd_pcm_dmaengine videobuf2_memops ecdh_generic sha2_ce ecc videobuf2_v4l2 snd_pcm v3d sha256_arm64 rfkill videodev snd_timer sha1_ce libaes gpu_sched snd videobuf2_common sha1_generic drm_shmem_helper mc rp1_pio drm_kms_helper raspberrypi_hwmon spi_bcm2835 gpio_keys i2c_brcmstb rp1 raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio i2c_dev drm ledtrig_pattern drm_panel_orientation_quirks backlight fuse dm_mod ip_tables x_tables ipv6<br /> [ 466.458429] CPU: 0 UID: 1000 PID: 2008 Comm: chromium Tainted: G C 6.13.0-v8+ #18<br /> [ 466.467336] Tainted: [C]=CRAP<br /> [ 466.470306] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)<br /> [ 466.476157] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 466.483143] pc : v3d_irq+0x118/0x2e0 [v3d]<br /> [ 466.487258] lr : __handle_irq_event_percpu+0x60/0x228<br /> [ 466.492327] sp : ffffffc080003ea0<br /> [ 466.495646] x29: ffffffc080003ea0 x28: ffffff80c0c94200 x27: 0000000000000000<br /> [ 466.502807] x26: ffffffd08dd81d7b x25: ffffff80c0c94200 x24: ffffff8003bdc200<br /> [ 466.509969] x23: 0000000000000001 x22: 00000000000000a7 x21: 0000000000000000<br /> [ 466.517130] x20: ffffff8041bb0000 x19: 0000000000000001 x18: 0000000000000000<br /> [ 466.524291] x17: ffffffafadfb0000 x16: ffffffc080000000 x15: 0000000000000000<br /> [ 466.531452] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 466.538613] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffd08c527eb0<br /> [ 466.545777] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 466.552941] x5 : ffffffd08c4100d0 x4 : ffffffafadfb0000 x3 : ffffffc080003f70<br /> [ 466.560102] x2 : ffffffc0829e8058 x1 : 0000000000000001 x0 : 0000000000000000<br /> [ 466.567263] Call trace:<br /> [ 466.569711] v3d_irq+0x118/0x2e0 [v3d] (P)<br /> [ 466.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()<br /> <br /> This patch addresses a null-ptr-deref in qt2_process_read_urb() due to<br /> an incorrect bounds check in the following:<br /> <br /> if (newport &gt; serial-&gt;num_ports) {<br /> dev_err(&amp;port-&gt;dev,<br /> "%s - port change to invalid port: %i\n",<br /> __func__, newport);<br /> break;<br /> }<br /> <br /> The condition doesn&amp;#39;t account for the valid range of the serial-&gt;port<br /> buffer, which is from 0 to serial-&gt;num_ports - 1. When newport is equal<br /> to serial-&gt;num_ports, the assignment of "port" in the<br /> following code is out-of-bounds and NULL:<br /> <br /> serial_priv-&gt;current_port = newport;<br /> port = serial-&gt;port[serial_priv-&gt;current_port];<br /> <br /> The fix checks if newport is greater than or equal to serial-&gt;num_ports<br /> indicating it is out-of-bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Ratelimit warning logs to prevent VM denial of service<br /> <br /> If there&amp;#39;s a persistent error in the hypervisor, the SCSI warning for<br /> failed I/O can flood the kernel log and max out CPU utilization,<br /> preventing troubleshooting from the VM side. Ratelimit the warning so<br /> it doesn&amp;#39;t DoS the VM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix ets qdisc OOB Indexing<br /> <br /> Haowei Yan found that ets_class_from_arg() can<br /> index an Out-Of-Bound class in ets_class_from_arg() when passed clid of<br /> 0. The overflow may cause local privilege escalation.<br /> <br /> [ 18.852298] ------------[ cut here ]------------<br /> [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20<br /> [ 18.853743] index 18446744073709551615 is out of range for type &amp;#39;ets_class [16]&amp;#39;<br /> [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17<br /> [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [ 18.856532] Call Trace:<br /> [ 18.857441] <br /> [ 18.858227] dump_stack_lvl+0xc2/0xf0<br /> [ 18.859607] dump_stack+0x10/0x20<br /> [ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0<br /> [ 18.864022] ets_class_change+0x3d6/0x3f0<br /> [ 18.864322] tc_ctl_tclass+0x251/0x910<br /> [ 18.864587] ? lock_acquire+0x5e/0x140<br /> [ 18.865113] ? __mutex_lock+0x9c/0xe70<br /> [ 18.866009] ? __mutex_lock+0xa34/0xe70<br /> [ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0<br /> [ 18.866806] ? __lock_acquire+0x578/0xc10<br /> [ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> [ 18.867503] netlink_rcv_skb+0x59/0x110<br /> [ 18.867776] rtnetlink_rcv+0x15/0x30<br /> [ 18.868159] netlink_unicast+0x1c3/0x2b0<br /> [ 18.868440] netlink_sendmsg+0x239/0x4b0<br /> [ 18.868721] ____sys_sendmsg+0x3e2/0x410<br /> [ 18.869012] ___sys_sendmsg+0x88/0xe0<br /> [ 18.869276] ? rseq_ip_fixup+0x198/0x260<br /> [ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190<br /> [ 18.869900] ? trace_hardirqs_off+0x5a/0xd0<br /> [ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220<br /> [ 18.870547] ? do_syscall_64+0x93/0x150<br /> [ 18.870821] ? __memcg_slab_free_hook+0x69/0x290<br /> [ 18.871157] __sys_sendmsg+0x69/0xd0<br /> [ 18.871416] __x64_sys_sendmsg+0x1d/0x30<br /> [ 18.871699] x64_sys_call+0x9e2/0x2670<br /> [ 18.871979] do_syscall_64+0x87/0x150<br /> [ 18.873280] ? do_syscall_64+0x93/0x150<br /> [ 18.874742] ? lock_release+0x7b/0x160<br /> [ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0<br /> [ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210<br /> [ 18.879608] ? irqentry_exit+0x77/0xb0<br /> [ 18.879808] ? clear_bhb_loop+0x15/0x70<br /> [ 18.880023] ? clear_bhb_loop+0x15/0x70<br /> [ 18.880223] ? clear_bhb_loop+0x15/0x70<br /> [ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 18.880683] RIP: 0033:0x44a957<br /> [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10<br /> [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957<br /> [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003<br /> [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0<br /> [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001<br /> [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001<br /> [ 18.888395] <br /> [ 18.888610] ---[ end trace ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Initialize denominator defaults to 1<br /> <br /> [WHAT &amp; HOW]<br /> Variables, used as denominators and maybe not assigned to other values,<br /> should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported<br /> by Coverity.<br /> <br /> (cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7)

A flaw was found in npm-serialize-javascript. The vulnerability occurs because the serialize-javascript module does not properly sanitize certain inputs, such as regex or other JavaScript object types, allowing an attacker to inject malicious code. This code could be executed when deserialized by a web browser, causing Cross-site scripting (XSS) attacks. This issue is critical in environments where serialized data is sent to web clients, potentially compromising the security of the website or web application using this package.

A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.