| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A race condition was addressed with improved locking. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, watchOS 7.3, tvOS 14.4, iOS 14.4 and iPadOS 14.4. A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.. |
| A type confusion issue was addressed with improved state handling. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, tvOS 14.4, watchOS 7.3, iOS 14.4 and iPadOS 14.4, Safari 14.0.3. Processing maliciously crafted web content may lead to arbitrary code execution. |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, iOS 14.4 and iPadOS 14.4. A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.. |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, iOS 14.4 and iPadOS 14.4. A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.. |
| This issue was addressed by improved management of object lifetimes. This issue is fixed in iOS 12.5.2, iOS 14.4.2 and iPadOS 14.4.2, watchOS 7.3.3. Processing maliciously crafted web content may lead to universal cross site scripting. Apple is aware of a report that this issue may have been actively exploited.. |
| In the Linux kernel, the following vulnerability has been resolved:
udp: Deal with race between UDP socket address change and rehash
If a UDP socket changes its local address while it's receiving
datagrams, as a result of connect(), there is a period during which
a lookup operation might fail to find it, after the address is changed
but before the secondary hash (port and address) and the four-tuple
hash (local and remote ports and addresses) are updated.
Secondary hash chains were introduced by commit 30fff9231fad ("udp:
bind() optimisation") and, as a result, a rehash operation became
needed to make a bound socket reachable again after a connect().
This operation was introduced by commit 719f835853a9 ("udp: add
rehash on connect()") which isn't however a complete fix: the
socket will be found once the rehashing completes, but not while
it's pending.
This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a
client sending datagrams to it. After the server receives the first
datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to
the address of the sender, in order to set up a directed flow.
Now, if the client, running on a different CPU thread, happens to
send a (subsequent) datagram while the server's socket changes its
address, but is not rehashed yet, this will result in a failed
lookup and a port unreachable error delivered to the client, as
apparent from the following reproducer:
LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))
dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in
while :; do
taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &
sleep 0.1 || sleep 1
taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null
wait
done
where the client will eventually get ECONNREFUSED on a write()
(typically the second or third one of a given iteration):
2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused
This issue was first observed as a seldom failure in Podman's tests
checking UDP functionality while using pasta(1) to connect the
container's network namespace, which leads us to a reproducer with
the lookup error resulting in an ICMP packet on a tap device:
LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"
while :; do
./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &
sleep 0.2 || sleep 1
socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null
wait
cmp tmp.in tmp.out
done
Once this fails:
tmp.in tmp.out differ: char 8193, line 29
we can finally have a look at what's going on:
$ tshark -r pasta.pcap
1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2
2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164
6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55
7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)
9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096
12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0
On the third datagram received, the network namespace of the container
initiates an ARP lookup to deliver the ICMP message.
In another variant of this reproducer, starting the client with:
strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: unregister wiphy only if it has been registered
There is a specific error path in probe functions in wilc drivers (both
sdio and spi) which can lead to kernel panic, as this one for example
when using SPI:
Unable to handle kernel paging request at virtual address 9f000000 when read
[9f000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc
CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22
Hardware name: Atmel SAMA5
PC is at wiphy_unregister+0x244/0xc40 [cfg80211]
LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211]
[...]
wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000]
wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi]
wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4
spi_probe from really_probe+0x270/0xb2c
really_probe from __driver_probe_device+0x1dc/0x4e8
__driver_probe_device from driver_probe_device+0x5c/0x140
driver_probe_device from __driver_attach+0x220/0x540
__driver_attach from bus_for_each_dev+0x13c/0x1a8
bus_for_each_dev from bus_add_driver+0x2a0/0x6a4
bus_add_driver from driver_register+0x27c/0x51c
driver_register from do_one_initcall+0xf8/0x564
do_one_initcall from do_init_module+0x2e4/0x82c
do_init_module from load_module+0x59a0/0x70c4
load_module from init_module_from_file+0x100/0x148
init_module_from_file from sys_finit_module+0x2fc/0x924
sys_finit_module from ret_fast_syscall+0x0/0x1c
The issue can easily be reproduced, for example by not wiring correctly
a wilc device through SPI (and so, make it unresponsive to early SPI
commands). It is due to a recent change decoupling wiphy allocation from
wiphy registration, however wilc_netdev_cleanup has not been updated
accordingly, letting it possibly call wiphy unregister on a wiphy which
has never been registered.
Fix this crash by moving wiphy_unregister/wiphy_free out of
wilc_netdev_cleanup, and by adjusting error paths in both drivers |
| A use after free issue was addressed with improved memory management. This issue is fixed in Safari 16.4.1, iOS 15.7.5 and iPadOS 15.7.5, iOS 16.4.1 and iPadOS 16.4.1, macOS Ventura 13.3.1. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent reg-wait speculations
With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments
for the waiting loop the user can specify an offset into a pre-mapped
region of memory, in which case the
[offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the
argument.
As we address a kernel array using a user given index, it'd be a subject
to speculation type of exploits. Use array_index_nospec() to prevent
that. Make sure to pass not the full region size but truncate by the
maximum offset allowed considering the structure size. |
| Flock Safety LPR (License Plate Reader) devices with firmware through 2.2 have an on-chip debug interface with improper access control. |
| Flock Safety LPR (License Plate Reader) devices with firmware through 2.2 have cleartext storage of code. |
| Flock Safety LPR (License Plate Reader) devices with firmware through 2.2 have a hardcoded password for a system. |
| Flock Safety Gunshot Detection devices before 1.3 have a hardcoded password for a system. |
| Tenda AC6 V2.0 15.03.06.50 was discovered to contain a stack overflow in the page parameter in the DhcpListClient function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. |
| he Live Auction Cockpit in SAP Supplier Relationship Management (SRM) uses a deprecated java applet component within the affected SRM packages which allows an unauthenticated attacker to execute malicious script in the victim�s browser. This vulnerability has low impact on confidentiality and integrity within the scope of that victim�s browser, with no effect on availability of the application |
| The Live Auction Cockpit in SAP Supplier Relationship Management (SRM) uses a deprecated java applet component within the affected SRM packages which allows an unauthenticated attacker to craft a malicious link, which when clicked by a victim, redirects the browser to a malicious site. On successful exploitation, the attacker could cause low impact on confidentiality and integrity with no impact on the availability of the application. |
| The Live Auction Cockpit in SAP Supplier Relationship Management (SRM) uses a deprecated java applet component within the affected SRM packages which allows an unauthenticated attacker to send an malicious request to the application, which could disclose the internal version details of the affected system. This vulnerability has low impact on confidentiality, with no effect on integrity and availability of the application. |
| The Live Auction Cockpit in SAP Supplier Relationship Management (SRM) uses a deprecated java applet component, which allows an unauthenticated attacker to send malicious payload request in a specific encoding format. The servlet will then decode this malicious request which will result in deserialization of data in the application leading to execution of arbitrary OS command on target as SAP Administrator. This vulnerability has High impact on confidentiality, integrity, and availability of the application. |
| The Live Auction Cockpit in SAP Supplier Relationship Management (SRM) allows an unauthenticated attacker to submit an application servlet request with a crafted XML file which when parsed, enables the attacker to access sensitive files and data. This vulnerability has a high impact on the application's confidentiality, with no effect on integrity and availability of the application. |
| A weakness has been identified in D-Link DIR-816L 206b01. Affected by this issue is the function soapcgi_main of the file /soap.cgi. This manipulation of the argument service causes os command injection. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be exploited. This vulnerability only affects products that are no longer supported by the maintainer. |
