| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Missing authorization in Network in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via crafted network traffic. (Chromium security severity: Low) |
| A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed a repository contributor to cause the appliance to issue requests to attacker-controlled internal hosts, which could be chained to achieve remote code execution on the appliance. The secret scanning validator for GCP service account credentials trusted the token endpoint embedded in a committed credential and issued a request to it without restricting the destination. Exploitation required an authenticated user with permission to push to a repository on an instance with GitHub Advanced Security and secret scanning validity checks enabled, a non-default configuration. This vulnerability affected GitHub Enterprise Server 3.20, 3.21, and 3.22 and was fixed in versions 3.20.9, 3.21.7, and 3.22.2. This vulnerability was reported through the GitHub Bug Bounty program. |
| Use after free in Core in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix runt reassembly panic from short inner tot_len
When the start of an inner packet is split across two outer packets
such that fewer than 4 bytes land at the end of the first one,
__input_process_payload() saves those bytes as a runt and skips the
iplen/iphlen validation performed for in-place packets. When the
continuation packet arrives, iptfs_reassem_cont() only requires the
declared inner length to be >= sizeof(ra_runt) (6) before allocating
the reassembly skb with that attacker-controlled length.
However, __iptfs_iphlen() always returns the fixed minimum IP header
size (20 for IPv4, 40 for IPv6), so for an inner IPv4 tot_len in
[6, 19] the header-completion copy writes past the declared packet
length, and the subsequent "ipremain -= copylen" underflows to ~4GB,
leaving the payload copy length bounded only by blkoff (up to 64KB).
At runtime the skb_put() tailroom check turns this into
skb_over_panic(), i.e. an unprivileged kernel panic (DoS), reachable
locally via userns+netns IPTFS SAs and remotely against IPTFS VPN
gateways when the decrypted outer skb is linear (e.g. AF_PACKET taps,
tun/tap delivery).
Align the runt path with the normal path by requiring the declared
inner length to cover at least the IP header size. This also subsumes
the previous >= sizeof(ra_runt) check, since the minimum IP header
is always larger than the runt buffer.
This issue was found by the autokbug dynamic kernel fuzzer at
Tencent Yunding Lab. |
| Authentication bypass OAuth device authorization flow in Devolutions Server 2026.3.7.0 and earlier allows a remote attacker to take over a user's account via replay of a captured device verification link by an authenticated victim. |
| Incorrect reference resolution in Autofill in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: High) |
| Information leak in Proxy in Google Chrome on on Windows prior to 155.0.8059.39 allowed an adjacent attacker to obtain sensitive information via crafted network traffic. (Chromium security severity: High) |
| In affected versions of Octopus Server, an authenticated user with permission to modify roles could bypass the protections preventing access abuse resulting in privilege escalation. It was possible for the built-in role to be weakened and the attacker's account added to a privileged team. This was achievable due to improper validation of unsafe equivalence in inputs. |
| Insertion of Sensitive Information into Log File in certain ASUS router models allows a remote authenticated attacker to obtain DDNS credentials from the system log, potentially enabling modification of DNS settings.Refer to the ' Security Update for ASUS Router Firmware ' section on the ASUS Security Advisory for more information. |
| A predictable seed in the pseudo-random number generator (PRNG) in the IFTTT pairing token generation of the ASUS RT-BE57 router allows an unauthenticated nearby user to derive the pairing token and read or modify router settings via observed values from an administrator-initiated IFTTT pairing session.Refer to the ' Security Update for ASUS Router Firmware ' section on the ASUS Security Advisory for more information. |
| Information leak in Audio in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted Chrome extension. (Chromium security severity: Medium) |
| An HTTP header injection vulnerability in start-page-loader.cgi of ADM allows an unauthenticated remote attacker to read arbitrary files on the host system. By sending a crafted HTTP request with injected headers via the state parameter, the attacker can leverage the underlying web server's X-Sendfile mechanism to retrieve sensitive files without authentication.
Affected products and versions include: from ADM 4.1.0 through ADM 4.3.3.RWC1 as well as from ADM 5.0.0 through ADM 5.1.4.RL21. |
| In wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an authorization check and are not capped in number, allowing a malicious SSH peer to make an endpoint allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client also does not check a forwarded-tcpip open against the forwards it registered with a tcpip-forward request, as RFC 4254 section 7.2 requires, so a malicious server can open forwarding channels for addresses and ports the client never asked it to forward. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel_pcie: validate TX skb length in send_sync
btintel_pcie_prepare_tx() copies skb->len bytes into a fixed
BTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy.
Oversized packets are currently rejected only in
btintel_pcie_send_frame(); any future caller of
btintel_pcie_send_sync() would silently overflow the DMA buffer.
Add the bounds check in btintel_pcie_send_sync() itself, right
before skb_push() and the DMA copy. |
| In the Linux kernel, the following vulnerability has been resolved:
net: fddi: skfp: fix NULL deref when setting the MAC address while down
skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without
checking netif_running(). ResetAdapter() first calls card_stop(), which
sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(),
which walks the two transmit queues:
for (i = QUEUE_S; i <= QUEUE_A0; i++) {
queue = smc->hw.fp.tx[i] ;
...
t = queue->tx_curr_get ;
smc->hw.fp.tx[] is only populated by init_tx(), which is reached from
skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() ->
init_mac() -> init_tx(). The private area is allocated and zeroed by
alloc_fddidev(), so on an interface that has never been brought up both
queue pointers are still NULL. The hw_state test at the top of
mac_drv_clear_tx_queue() does not catch this, because card_stop() has
just set STOPPED; the function proceeds into the loop and dereferences
NULL. ResetAdapter() does call init_smt() itself, but only after the
queues have been cleared.
Setting the MAC address on a down interface therefore oopses:
ip link set dev fddi0 address 02:00:00:00:00:01
BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp]
Read of size 8 at addr 0000000000000010 by task ip/302
Call Trace:
<TASK>
mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
netif_set_mac_address+0x1e4/0x2c0
do_setlink+0x684/0x2680
</TASK>
Address 0x10 is the offset of tx_curr_get, the third pointer in
struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which
ResetAdapter() calls immediately afterwards, dereferences
smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective
hw_state test; the transmit queue merely crashes first. Both are
covered by the guard below.
Skip the adapter reset when the interface is down. dev_addr_set() is
left unconditional, so the new address is still recorded in
dev->dev_addr. Nothing is lost by not resetting the adapter here:
skfp_open() deliberately re-reads the factory address on every open,
read_address(smc, NULL);
eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a);
and the comment above it states this is done to discard exactly such an
address override across a close/open cycle. An address set while the
interface is down could not have survived the following open even
before this change, so the guard removes no working behaviour. Guarding
the hardware side of ndo_set_mac_address() with netif_running() is
established practice; skge_set_mac_address() has done so since commit
2eb3e621c4e0 ("skge: set mac address bonding fix").
Guarding the reset as a whole, rather than NULL-checking the queues, is
also what the rest of the driver expects. After a previous open/close
the queue pointers are stale but non-NULL, so there is no crash, yet
ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable
Board Interrupts") while skfp_close() has already called free_irq() -
the adapter would be brought back online with no handler installed. The
only other ResetAdapter() caller is skfp_interrupt(), which by
construction runs only while the device is open.
Found by automated driver testing against an emulated SysKonnect FDDI
adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires
CAP_NET_ADMIN. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: set timer->private_data before registering the PCM timer
snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer->private_data = substream.
Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer->private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:
substream = timer->private_data;
return substream->runtime ? ... // substream is NULL
Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream->timer = NULL, which is already NULL at that point
since substream->timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_nat: fully initialise new_addr in netmap setup
nft_nat_setup_netmap() builds the mapped address in an on-stack
union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip
member and the loop runs a single 32-bit iteration, but it then copies
the whole 16-byte union into range->min_addr and range->max_addr, so the
upper 12 bytes reach nf_nat_setup_info() uninitialised.
KMSAN reports an uninit-value in nf_nat_setup_info() reached from
nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected.
Zero-initialise new_addr. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: only operate on TDLS peers in the TDLS code
ieee80211_tdls_oper() can operate on the AP station, which then
yields various warnings when the AP station is removed then or
at a later point in time after being confused for a TDLS peer.
Always check that the station is a TDLS peer. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: abort chanswitch when leaving a mesh
The code in ieee80211_stop_mesh() leaves CSA active, but leaving
the mesh released the channel context, so the CSA finalize work
crashes:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272
Call Trace:
ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093
ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147
ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542
ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline]
__ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline]
ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155
cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438
Abort the channel switch properly. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't offload TC setup on AP_VLAN interfaces
AP_VLAN interfaces are purely virtual, so don't try to offload
TC setup to drivers. We can't really use the AP interface either
since we may not know it all the time, and it could technically
even change.
Just reject the TC offload so things get done in software. |
