| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix key reference count leak from call->key
When creating a client call in rxrpc_alloc_client_call(), the code obtains
a reference to the key. This is never cleaned up and gets leaked when the
call is destroyed.
Fix this by freeing call->key in rxrpc_destroy_call().
Before the patch, it shows the key reference counter elevated:
$ cat /proc/keys | grep afs@54321
1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka
$
After the patch, the invalidated key is removed when the code exits:
$ cat /proc/keys | grep afs@54321
$ |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Only put the call ref if one was acquired
rxrpc_input_packet_on_conn() can process a to-client packet after the
current client call on the channel has already been torn down. In that
case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is
no reference to drop.
The client-side implicit-end error path does not account for that and
unconditionally calls rxrpc_put_call(). This turns a protocol error
path into a kernel crash instead of rejecting the packet.
Only drop the call reference if one was actually acquired. Keep the
existing protocol error handling unchanged. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: reject undecryptable rxkad response tickets
rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then
parses the buffer as plaintext without checking whether
crypto_skcipher_decrypt() succeeded.
A malformed RESPONSE can therefore use a non-block-aligned ticket
length, make the decrypt operation fail, and still drive the ticket
parser with attacker-controlled bytes.
Check the decrypt result and abort the connection with RXKADBADTICKET
when ticket decryption fails. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix RESPONSE authenticator parser OOB read
rxgk_verify_authenticator() copies auth_len bytes into a temporary
buffer and then passes p + auth_len as the parser limit to
rxgk_do_verify_authenticator(). Since p is a __be32 *, that inflates the
parser end pointer by a factor of four and lets malformed RESPONSE
authenticators read past the kmalloc() buffer.
Decoded from the original latest-net reproduction logs with
scripts/decode_stacktrace.sh:
BUG: KASAN: slab-out-of-bounds in rxgk_verify_response()
Call Trace:
dump_stack_lvl() [lib/dump_stack.c:123]
print_report() [mm/kasan/report.c:379 mm/kasan/report.c:482]
kasan_report() [mm/kasan/report.c:597]
rxgk_verify_response()
[net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167
net/rxrpc/rxgk.c:1274]
rxrpc_process_connection()
[net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364
net/rxrpc/conn_event.c:386]
process_one_work() [kernel/workqueue.c:3281]
worker_thread()
[kernel/workqueue.c:3353 kernel/workqueue.c:3440]
kthread() [kernel/kthread.c:436]
ret_from_fork() [arch/x86/kernel/process.c:164]
Allocated by task 54:
rxgk_verify_response()
[include/linux/slab.h:954 net/rxrpc/rxgk.c:1155
net/rxrpc/rxgk.c:1274]
rxrpc_process_connection()
[net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364
net/rxrpc/conn_event.c:386]
Convert the byte count to __be32 units before constructing the parser
limit. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix oversized RESPONSE authenticator length check
rxgk_verify_response() decodes auth_len from the packet and is supposed
to verify that it fits in the remaining bytes. The existing check is
inverted, so oversized RESPONSE authenticators are accepted and passed
to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an
impossible length and hit BUG_ON(len).
Decoded from the original latest-net reproduction logs with
scripts/decode_stacktrace.sh:
RIP: __skb_to_sgvec()
[net/core/skbuff.c:5285 (discriminator 1)]
Call Trace:
skb_to_sgvec() [net/core/skbuff.c:5305]
rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81]
rxgk_verify_response() [net/rxrpc/rxgk.c:1268]
rxrpc_process_connection()
[net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364
net/rxrpc/conn_event.c:386]
process_one_work() [kernel/workqueue.c:3281]
worker_thread()
[kernel/workqueue.c:3353 kernel/workqueue.c:3440]
kthread() [kernel/kthread.c:436]
ret_from_fork() [arch/x86/kernel/process.c:164]
Reject authenticator lengths that exceed the remaining packet payload. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix integer overflow in rxgk_verify_response()
In rxgk_verify_response(), there's a potential integer overflow due to
rounding up token_len before checking it, thereby allowing the length check to
be bypassed.
Fix this by checking the unrounded value against len too (len is limited as
the response must fit in a single UDP packet). |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix leak of rxgk context in rxgk_verify_response()
Fix rxgk_verify_response() to clean up the rxgk context it creates. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix buffer overread in rxgk_do_verify_authenticator()
Fix rxgk_do_verify_authenticator() to check the buffer size before checking
the nonce. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: proc: size address buffers for %pISpc output
The AF_RXRPC procfs helpers format local and remote socket addresses into
fixed 50-byte stack buffers with "%pISpc".
That is too small for the longest current-tree IPv6-with-port form the
formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a
dotted-quad tail not only for v4mapped addresses, but also for ISATAP
addresses via ipv6_addr_is_isatap().
As a result, a case such as
[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535
is possible with the current formatter. That is 50 visible characters, so
51 bytes including the trailing NUL, which does not fit in the existing
char[50] buffers used by net/rxrpc/proc.c.
Size the buffers from the formatter's maximum textual form and switch the
call sites to scnprintf().
Changes since v1:
- correct the changelog to cite the actual maximum current-tree case
explicitly
- frame the proof around the ISATAP formatting path instead of the earlier
mapped-v4 example |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix reference count leak in rxrpc_server_keyring()
This patch fixes a reference count leak in rxrpc_server_keyring()
by checking if rx->securities is already set. |
| In the Linux kernel, the following vulnerability has been resolved:
pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
Keep the NOC_HDCP clock always enabled to fix the potential hang
caused by the NoC ADB400 port power down handshake. |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG
The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements
bc_ackers on every inbound group ACK, even when the same member has
already acknowledged the current broadcast round.
Because bc_ackers is a u16, a duplicate ACK received after the last
legitimate ACK wraps the counter to 65535. Once wrapped,
tipc_group_bc_cong() keeps reporting congestion and later group
broadcasts on the affected socket stay blocked until the group is
recreated.
Fix this by ignoring duplicate or stale ACKs before touching bc_acked or
bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and
prevents the underflow path. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: make use of smbdirect_socket.recv_io.credits.available
The logic off managing recv credits by counting posted recv_io and
granted credits is racy.
That's because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the 'recv_done' functions
we likely have a window where we grant credits, which
don't really exist.
So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: server: make use of smbdirect_socket.recv_io.credits.available
The logic off managing recv credits by counting posted recv_io and
granted credits is racy.
That's because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the 'recv_done' functions
we likely have a window where we grant credits, which
don't really exist.
So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.
This fixes regression Namjae reported with
the 6.18 release. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: introduce smbdirect_socket.recv_io.credits.available
The logic off managing recv credits by counting posted recv_io and
granted credits is racy.
That's because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the 'recv_done' functions
we likely have a window where we grant credits, which
don't really exist.
So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix trace_marker copy link list updates
When the "copy_trace_marker" option is enabled for an instance, anything
written into /sys/kernel/tracing/trace_marker is also copied into that
instances buffer. When the option is set, that instance's trace_array
descriptor is added to the marker_copies link list. This list is protected
by RCU, as all iterations uses an RCU protected list traversal.
When the instance is deleted, all the flags that were enabled are cleared.
This also clears the copy_trace_marker flag and removes the trace_array
descriptor from the list.
The issue is after the flags are called, a direct call to
update_marker_trace() is performed to clear the flag. This function
returns true if the state of the flag changed and false otherwise. If it
returns true here, synchronize_rcu() is called to make sure all readers
see that its removed from the list.
But since the flag was already cleared, the state does not change and the
synchronization is never called, leaving a possible UAF bug.
Move the clearing of all flags below the updating of the copy_trace_marker
option which then makes sure the synchronization is performed.
Also use the flag for checking the state in update_marker_trace() instead
of looking at if the list is empty. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/platform/uv: Handle deconfigured sockets
When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes
a panic while allocating UV hub info structures.
Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be
allocated on valid nodes. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix NULL dereference on notify error path
Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier
registration for unsupported events") the call chains leading to the helper
__scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to
get an handler for the requested event key, while the current helper can
still return a NULL when no handler could be found or created.
Fix by forcing an ERR_PTR return value when the handler reference is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
NFC: nxp-nci: allow GPIOs to sleep
Allow the firmware and enable GPIOs to sleep.
This fixes a `WARN_ON' and allows the driver to operate GPIOs which are
connected to I2C GPIO expanders.
-- >8 --
kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98
-- >8 -- |
| In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix NULL deref in bond_debug_rlb_hash_show
rlb_clear_slave intentionally keeps RLB hash-table entries on
the rx_hashtbl_used_head list with slave set to NULL when no
replacement slave is available. However, bond_debug_rlb_hash_show
visites client_info->slave without checking if it's NULL.
Other used-list iterators in bond_alb.c already handle this NULL-slave
state safely:
- rlb_update_client returns early on !client_info->slave
- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance
compare slave values before visiting
- lb_req_update_subnet_clients continues if slave is NULL
The following NULL deref crash can be trigger in
bond_debug_rlb_hash_show:
[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)
[ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286
[ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204
[ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078
[ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000
[ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0
[ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8
[ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000
[ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0
[ 1.295897] Call Trace:
[ 1.296134] seq_read_iter (fs/seq_file.c:231)
[ 1.296341] seq_read (fs/seq_file.c:164)
[ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))
[ 1.296658] vfs_read (fs/read_write.c:572)
[ 1.296981] ksys_read (fs/read_write.c:717)
[ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
[ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Add a NULL check and print "(none)" for entries with no assigned slave. |
