| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Improper Initialization vulnerability in the SSR software in Juniper Networks Session Smart Router allows an attacker to decrypt traffic or cause a denial of service via security policy assignment. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: hdmi: Move packet RAM enable to PM runtime
Audio can be triggered by the HPD handler and start up before video has
been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe.
vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the
infoframe, however, if the video hasn't been enabled,
vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the
Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes,
causing the following splat:
[ 201.570266] ------------[ cut here ]------------
[ 201.570293] Packet RAM has to be on to store the packet.
[ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606
[...]
[ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[...]
[ 201.758499] Call trace:
[ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P)
[ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4]
[ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper]
[ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper]
[ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4]
[ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper]
[ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec]
[ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core]
[ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core]
[ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core]
[ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm]
[ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm]
[ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm]
[ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm]
[ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm]
[ 201.846802] __arm64_sys_ioctl+0x88/0xd8
[ 201.850769] invoke_syscall+0x48/0xf4
[ 201.854470] el0_svc_common+0x80/0xd8
[ 201.858171] do_el0_svc+0x1c/0x28
[ 201.861520] el0_svc+0x3c/0xb0
[ 201.864605] el0t_64_sync_handler+0x68/0xdc
[ 201.868834] el0t_64_sync+0x198/0x19c
[ 201.872536] ---[ end trace 0000000000000000 ]---
Considering that Packet RAM enable is essentially a power management
configuration, move its enabling/disabling to the Runtime PM hooks.
Note that post_crtc_disable() still stops all infoframes, but keeps Packet
RAM enabled, leaving it to be disabled by runtime suspend. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Zero OA buffer at allocation
ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and
may contain data from previously freed pages. Since the OA buffer is
mmap'able by userspace, this can expose stale kernel memory contents.
Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA
buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at
allocation to prevent information disclosure through mmap.
The existing zeroing in xe_oa_init_oa_buffer() remains necessary for
zero report-id/timestamp detection on enable/re-enable.
(cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: treat TCP_CLOSING as once-established
Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can
race with the connect loop. Immediately break and return 0 on
ESTABLISHED/CLOSING. The return value of connect() should reflect what
happened up to the point the connection was established or failed. Events
that occur afterwards must not affect it. E.g. even if OP_RW has already
set sk_err, connect() should still return 0, not ENOBUFS because of it.
Adapt the inaccurate comment above signal_pending().
Resetting a socket that is still present in connected_table can lead to
memory corruption. The reporter noted lost transports for in-flight skbs,
and I have reproduced crashes caused by re-insertion into connected_table.
list_add double add: new=, prev=, next=.
kernel BUG at lib/list_debug.c:35!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:__list_add_valid_or_report+0x11f/0x130
Call Trace:
vsock_insert_connected.cold+0xe/0x13
virtio_transport_recv_pkt+0x10e9/0x1460
vsock_loopback_work+0x305/0x480
process_one_work+0xe4c/0x1560
worker_thread+0x4f1/0xd60
kthread+0x36e/0x470
ret_from_fork+0x47b/0x6b0
ret_from_fork_asm+0x1a/0x30
This fix is supplementary to commit 002541ef650b ("vsock: Ignore
signal/timeout on connect() if already established"). Details under Link. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION
smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION,
that is the whole of struct smb2_fs_control_info, but never assigns
FileSystemControlFlags. Those four bytes go to the client as they are
found in the response buffer.
The buffer is zeroed on allocation, so a standalone request leaks
nothing. A compound request can leak: the offset of the next response
is advanced by the length pinned for the previous one, so a reply that
was written into the buffer and then dropped in favour of the short
error response of smb2_set_err_rsp() stays there, and the next reply is
laid over it with only the header cleared.
ksmbd does not implement quota tracking, so report no control flags. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/insn-eval: Fix shadowed segment index in get_seg_reg_override_idx()
Commit 45e1dccc0653 ("x86/insn: Simplify for_each_insn_prefix()") made
for_each_insn_prefix() declare its own loop counter named idx.
get_seg_reg_override_idx() keeps its result in a local of the same name,
so the assignments in the loop body now write the loop counter:
- the function always returns INAT_SEG_REG_DEFAULT, so FS and GS
overrides are ignored;
- a CS override sets the counter to INAT_SEG_REG_CS (2), the increment
makes it 3, and prefixes.bytes[3] holds the last prefix, 0x2e again,
so the loop never terminates.
The UMIP emulation reaches this from the #GP handler for user space: an
SGDT, SIDT or SMSW with a memory operand and a CS prefix leaves the task
spinning in the kernel, never returning to user space, with a SIGKILL
that is never delivered. Any user can thus tie up CPUs until reboot.
With an FS or GS prefix, the emulated result is written to the wrong
address.
Rename the internal macro iterator variable.
[ Lukas' original patch renamed the use site, I changed it to rename the
iterator in the macro instead, but left Lukas' commit message and
authorship - Linus ] |
| In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix the recvmsg window update
iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without
testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes
the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2
is zero and one recvmsg() on its own socket is enough for an unprivileged
process to take a spurious disconnect.
It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which
allocates GFP_KERNEL inside a section the code treats as atomic. Sending
outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where
msg_recv is sampled for the advertised window and subtracted after
dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock()
while recvmsg holds no socket lock, so both can subtract the same value,
the counter goes negative and the credit reaches the peer twice.
Test the transport, claim the credit with atomic_xchg() after the last
error exit and hand it back if the transmit fails, and send once the lock
is dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
page_pool: keep frag_offset aligned for odd-sized requests
page_pool_alloc_frag_netmem() rounds the requested fragment size with
size = ALIGN(size, dma_get_cache_alignment());
dma_get_cache_alignment() returns 1 unless the architecture defines
ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not.
There the ALIGN() is a no-op and pool->frag_offset advances by the raw,
unrounded size.
A single caller asking for an odd size then leaves frag_offset misaligned
for every fragment carved out of that page afterwards. The pool is shared,
so the damage is not confined to the caller that caused it.
The per-cpu system_page_pool used by generic XDP hits this.
skb_pp_cow_data() allocates its fragments with the raw packet length:
size = min_t(u32, len, PAGE_SIZE);
truesize = size;
page = page_pool_dev_alloc(pool, &page_off, &truesize);
leaving frag_offset odd for whatever is carved out of that page next. Its
own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the
XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared
pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer,
napi_build_skb() installs it as skb->head, and skb_shinfo(skb) ==
skb->head + skb->end is misaligned with it.
skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the
atomic_inc() in __skb_clone() straddles a cache line. On x86 with split
lock detection -- fatal for kernel split locks by default -- this panics
the machine:
Oops: Split lock detected
RIP: 0010:skb_clone+0x154/0x1e0
Call Trace:
<IRQ>
raw_local_deliver+0x1ed/0x2c0
ip_protocol_deliver_rcu+0x54/0x1c0
ip_local_deliver_finish+0x85/0x100
ip_local_deliver+0x67/0x100
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0x87/0x130
Reproduced by attaching any generic-mode XDP program to loopback and
opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone
every locally delivered UDP packet; ordinary DNS traffic then triggers it,
roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8.
Tracing page_pool_alloc_frag_netmem() over one such run shows the
amplification -- two odd-sized requests, nine misaligned offsets:
requested size & 7: 0: 17035 5: 1 7: 1
frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5
and skb_pp_cow_data() returning heads that were aligned on entry:
head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4)
head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)
Round the fragment size up to at least the alignment struct skb_shared_info
requires, so fragments are always suitably aligned for the objects callers
build on them. Architectures needing a larger DMA alignment keep it.
This also makes the remainder computed in page_pool_alloc_netmem(),
*size = max_size - *offset;
aligned, since max_size is a power of two -- which fixes the matching
misalignment of skb->end.
Verified with a controlled A/B under QEMU/KVM: same tree, same config,
same compiler, same rootfs and identical traffic, differing only by this
patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams
larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which
passes raw packet lengths to the pool. Measured at the return of
skb_pp_cow_data():
unpatched patched
skb_pp_cow_data calls 40800 40800
misaligned skb->head 1120 0
dataref at line offset >60 80 0
The last row counts the accesses that actually fault:
skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so
`lock incl` splits a 64-byte cache line only when that address lands at
offset 61..63. All 80 occurrences were at offset 61; the panic reported
above was at offset 62. Eliminating the misalignment removes every one
of them.
Same class of bug as commit 3bed3cc4156e ("net: Do not allocate page
fragments t
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
s390/pai: Handle multiple PMU stop callback invocations
Handle the following scenario:
The kernel protects itself against a very high sampling load and
throttles the sampling using:
perf_event_throttle() --> PMU->stop()
Shortly later the scheduler may terminate the task and removes it from the
CPU. It again calls
PMU->stop()
which results in two invocations of PMU->stop() called back to back.
Protect against this and check the PERF_HES_STOPPED bit on function
entry. If it is already set return.
Clear bit PERF_HES_STOPPED in PMU->start().
Prohibit ioctl(fd, PERF_EVENT_IOC_PERIOD, ...) call for this event.
It sets perf_event::event_limit to a positive value and causes
perf_event_overflow() to invoke pai_stop() call back function when
perf_event::event_limit hits zero. This is not supported because the
sample events CRYPTO_ALL and NNPA_ALL are only taken at schedule out
of a task.
Use list_for_each_entry_safe() for safe iteration over syswide_list
in pai_have_samples(). |
| In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor
scx_bypass() claims bypass dispatch when the scheduler's depth goes from
zero to one and releases it when the depth returns to zero, but propagates
only the depth to the descendants, not the claim. A descendant that starts
bypassing with its ancestor never claims, and one whose own bypass ends
under the ancestor's keeps its claim, as its depth does not return to zero.
A sub-scheduler enable whose bypass ends under a PM suspend thus leaks its
claim: the parent keeps hosting bypass dispatch and the sub-scheduler's next
bypass trips the WARN_ON_ONCE() on the claim. A sub-scheduler disable that
starts under a PM suspend has no claim, so once the resume lifts the root's
bypass its tasks sit on the parent's bypass DSQs with nobody consuming them.
Claim for every descendant whose depth goes from zero to one in the
propagation and release every scheduler in the subtree whose depth returned
to zero once the tasks have moved out of the bypass DSQs. A parent that is
bypassing itself when a descendant claims consumes only its own bypass DSQs,
empty until it leaves bypass and becomes the host. |
| Incorrect boundary conditions in the DOM: Service Workers component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. |
| Sandbox escape due to invalid pointer in the Graphics: WebRender component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. |
| Invalid pointer in the JavaScript Engine: JIT component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. |
| Invalid pointer in the Graphics: WebRender component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. |
| A memory initialization issue was addressed with improved memory handling. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. Processing a maliciously crafted image may result in disclosure of process memory. |
| A type confusion issue was addressed with improved checks. This issue is fixed in iOS 27.2 and iPadOS 27.2. An app may be able to access sensitive user data. |
| A type confusion issue was addressed with improved memory handling. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination. |
| An uninitialized memory issue was addressed with improved memory handling. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. Processing a maliciously crafted image may result in disclosure of process memory. |
| A memory initialization issue was addressed with improved memory handling. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to disclose kernel memory. |
| Invalid pointer, undefined behavior in the DOM: Notifications component. This vulnerability was fixed in Firefox 158 and Thunderbird 158. |
