| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Eladmin through 2.7 contains a missing authorization vulnerability in the LocalStorageController uploadPicture handler that allows low-privileged authenticated users to bypass the storage:add permission. Attackers can send POST requests with image-named files to /api/localStorage/pictures to write files into server local storage and disclose absolute server paths. |
| 1Panel-dev CordysCRM before 1.9.2 contains a missing authorization vulnerability that allows authenticated users to list business titles by calling POST /field/source/business-title without permission checks. Users lacking CONTRACT_BUSINESS_TITLE_READ can retrieve organization invoicing entities, exposing tax identification numbers, bank account numbers, opening banks, registration addresses, and phone numbers. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel_pcie: fix off-by-one bounds check in RX submit
btintel_pcie_submit_rx() used frbd_index > rxq->count to guard the
FRBD array access, allowing frbd_index == rxq->count to pass through
and index one element past the end of the array. Change the check to
>= rxq->count so every out-of-range index is rejected.
This issue was reported by Claude Mythos. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: set up the TX info early to fix failure paths
The previous commit 2c51457d930f ("wifi: mac80211: free ack status
frame on TX header build failure") cleaned up the leak, but still
left the code a bit messy and the failed SKB didn't get reported
to userspace.
Fix this up by initialising skb->cb[] earlier, which allows using
ieee80211_free_txskb() and therefore reports it for the failure
in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize()
failure path with it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: get the wiphy out of a dying network namespace
When a network namespace is destroyed, cfg80211_pernet_exit() moves any
wiphy back to the initial namespace, and just warns if that fails. But
moving an interface can fail (due to allocation failures), and then the
wiphy is left behind with a garbage netns pointer:
Kernel mode fault at addr 0x30
genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211]
nl80211_notify_wiphy+0xcd/0xe8 [cfg80211]
wiphy_unregister+0x169/0x3fc [cfg80211]
Note that commit debac3a20dec ("net: Remove conflicting altnames for
dying netns in __dev_change_net_namespace().") fixed another path
that could reach it without allocation failures.
Remove interfaces that cannot be moved instead of failing the switch,
so that the wiphy always ends up in the initial namespace. In this
case the netdev core will unregister the interfaces anyway. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: unlist vifs when their netdev is unregistered
mac80211 only removes vifs from the local->interfaces list when
an interface is removed via ieee80211_if_remove(), before it
unregisters the netdev. However, it's possible for a netdev to
be unregistered without going through that: When the netns that
holds the wiphy is destroyed, the wiphy is supposed to move to
the init_ns, but that can run into allocation failures.
Then, mac80211 has an interface listed that doesn't exist, and
will eventually hit
BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()!
...
_cfg80211_unregister_wdev+0x24/0x36a [cfg80211]
cfg80211_unregister_wdev+0x15/0x1d [cfg80211]
ieee80211_remove_interfaces+0x1ff/0x257 [mac80211]
ieee80211_unregister_hw+0x73/0x1d1 [mac80211]
mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim]
Remove the interface from the list in ->ndo_uninit if it's still
around to avoid this. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't start a ROC while scanning
The ROC work can be pending when a scan starts (which requires
ROC list to be empty, but that's possible), and then a new ROC
can be added to the list and the work will pick it up.
Avoid starting that ROC if a scan made it between things, as
otherwise we'll hit a warning later:
WARNING: net/mac80211/offchannel.c:404 at ieee80211_start_next_roc+0x256/0x2d0
Workqueue: events_unbound cfg80211_wiphy_work
Call Trace:
__ieee80211_scan_completed+0x4fd/0xe40 net/mac80211/scan.c:537
ieee80211_scan_work+0x472/0x1ff0 net/mac80211/scan.c:1193
cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513 |
| 1Panel-dev CordysCRM through 1.9.3 lacks a PROCESS_SETTING permission check on POST /approval-flow/webhook/test, allowing any authenticated user to trigger server-side requests to attacker-supplied URLs. Attackers can redirect GET requests from a controlled host to bypass SSRFValidator and probe internal addresses through success or failure results. |
| CordysCRM through 1.9.3 contains a missing authorization vulnerability in POST /approval-resource/push that allows authenticated users to submit any resource for approval without ownership checks. Low-privileged attackers can supply arbitrary resourceId values for contracts, invoices, quotations or orders to alter their approval status and read approval details. |
| eladmin through commit 55fbf70 contains a missing authorization vulnerability in the downloadS3Storage handler that allows any authenticated user to retrieve stored object URLs without storage permissions. Attackers can enumerate sequential ids against GET /api/s3Storage/download/{id} to collect URLs of all uploaded objects, exposing file contents on publicly readable buckets. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: exclude old ACKs from tcp fast path
Exclude old ACKs before SND.UNA from the tcp fast path
as well as ACKs after SND.NXT.
Such ACKs will fall through to the slow path, where tcp_ack()
performs the appropriate validation and challenge ACK handling
according to RFC5961 and Commit 3d501dd326fb1c7 ("tcp: do not
accept ACK of bytes we never sent").
This prevents old ACKs from being accepted
or modifying connection state as part of the fast path before
appropriate ACK validation is applied.
In particular, this prevents payload carried by a segment with
an excessively old ACK from advancing RCV.NXT before the ACK
is rejected. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type
stream_config is not initialized before being passed to
sdw_stream_add_slave(). The type field may contain garbage and is
later copied to stream->type by sdw_config_stream().
Zero-initialize stream_config so type defaults to SDW_STREAM_PCM.
While at it, use snd_sdw_params_to_config() helper instead of
open-coding the same logic. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity
data_ep_set_params() allocates each data URB for exactly u->packets
isochronous frames, so urb->iso_frame_desc[] has u->packets slots and
ctx->packets is the driver's only record of that limit. For an implicit
feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the
sync source's packet count, which is calculated independently from the
capture endpoint's parameters. When that count is larger,
prepare_playback_urb() and prepare_silent_urb() can write
iso_frame_desc[] past the allocation; their existing bounds limit payload
bytes, not the descriptor index.
The reproducer uses a high-speed UAC2 device declaring bInterval 1 for
implicit feedback capture (8 packets) and bInterval 4 for playback
(1 packet). On the first capture completion after the stream starts, it
accesses seven descriptors spanning 112 bytes beyond the one-packet URB:
BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560)
Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178
prepare_playback_urb (sound/usb/pcm.c:1560)
prepare_outbound_urb (sound/usb/endpoint.c:340)
snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501)
snd_complete_urb (sound/usb/endpoint.c:1834)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)
vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107)
kthread (kernel/kthread.c:436)
The buggy address belongs to the object at ffff88801e696a00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0)
Record the allocated packet count per endpoint and clamp both the adopted
count and the packet-size copy to it. Fold the Format Type II delimiter
into urb_packs before the allocation loop so the recorded limit matches
every URB. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix potential UAF after asynchronous card release
Usually a sound driver releases the resources assigned to the card via
snd_card_free(), and it synchronizes with the whole release procedure.
However, when the card is released asynchronously via
snd_card_free_when_closed() like USB-audio driver, the situation is
slightly different; although the snd_card_disconnect() call at the
disconnection guarantees that any newer accesses will be gated, the
in-flight tasks might be still accessing to the underlying card->dev
device even after the disconnection, which would cause a
use-after-free in the end, as reported by fuzzers.
For addressing the bug above, this patch takes the refcount of
card->dev at initialization of the card object, and releases at its
destructor. This assures the availability of the card->dev in its
whole lifecycle. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: ibss: ref BSS entry for joined event
When the IBSS is joined, we only record the BSSID/channel in the event
and look up the BSS entry when processing it. However, that's racy,
e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a
warning in the event work:
!bss
WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440
Workqueue: cfg80211 cfg80211_event_work
cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144
cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179
cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393
Do the lookup early (the driver is expected to only join an IBSS that
has a BSS entry) and keep a reference to it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: don't filter by BSS type when removing stale entries
When an assoc AP switches to a channel that already has a BSS entry,
cfg80211_update_assoc_bss_entry() removes that entry before rehashing
the real one, since the two would otherwise collide in the BSS rbtree.
The lookup for that entry also required it to match the connection's BSS
type, so an entry advertising e.g. the IBSS capability bit was left in
place, and the following cfg80211_rehash_bss() then ran into it:
WARN_ON(!cmp)
Changing the type shouldn't really happen, but can be triggered by a
rogue AP/device, so drop the check and remove any entries matching
the comparison. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: only group hidden BSSes with beacon entries
When a probe response for an unknown BSS comes in, __cfg80211_bss_update()
looks for an existing entry with the same BSSID and a hidden (zero-length
or NUL-filled) SSID, and if it finds one it groups them, using the beacon
IEs from the existing entry.
But that could find another entry without a beacon, if it was also from a
probe response (with SSID), so there's a group without beacon elements.
If a beacon with a hidden SSID for that BSSID arrives later,
cfg80211_combine_bsses() goes looking for the probe response entries that
belong to it - i.e. entries with the same BSSID and channel that have no
beacon IEs - and finds those two. They are already grouped with each
other, so it hits its
WARN_ON_ONCE(bss->pub.hidden_beacon_bss)
WARN_ON_ONCE(!list_empty(&bss->hidden_list))
which are there because an entry without beacon elements is not supposed
to be part of a group yet.
Only combine entries when a beacon was already received, ones that are
kept separate will be combined when a beacon arrives. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix device kref underflow in dma_chan_put()
dma_chan_get() takes chan->device->ref only on the slow path:
/* no kref on fast path */
if (chan->client_count) {
__module_get(owner);
chan->client_count++;
return 0;
}
if (!try_module_get(owner))
return -ENODEV;
if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero()
dma_chan_put() drops the ref unconditionally, so every fast-path
get/put pair drops one extra device reference.
The bug fires when two conditions hold together: a non-private
provider has a persistent client holding chan->client_count > 0
and another client cycles dmaengine_get()/dmaengine_put().
When the kref hits zero, the subsequent dma_find_channel() returns
NULL even though the provider module is still loaded.
Fix this by dropping device->ref only on the last put, matching the
single slow-path get. |
| In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: drop RX packets with a short Ethernet header
handle_incoming_queue() pulls pull_to bytes into the head before
calling eth_type_trans(). pull_to is the length of the first RX slot,
capped at RX_COPY_THRESHOLD, and that length comes from the backend.
Nothing checks it against ETH_HLEN.
If the first slot is shorter than ETH_HLEN and more slots follow, the
head ends up shorter than an Ethernet header while skb->len is longer,
and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is
shorter than ETH_HLEN, eth_type_trans() reads the header past the end
of the data instead.
Pull at least ETH_HLEN, and drop the packet if that fails, which also
drops packets too short to hold an Ethernet header. This also checks
the return value of the pull, which was ignored. |
| In the Linux kernel, the following vulnerability has been resolved:
vlan: require the MAC header to be present in __vlan_insert_inner_tag()
__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present. Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb->data: a 12-byte
memmove plus two 2-byte stores at +12 and +14. No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().
An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame. The first vlan push only sets a
hwaccel tag; the next - clsact "action vlan push" or
bpf_skb_vlan_push() - enters the helper with skb->len still 1. The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb->tail into the frame. After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:
0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
`------------------------------'
only 0x5a was sent; the rest is slab, here the top 56 bits of a
linear-map address
Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted. |
