Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht
net: ethernet: mtk_eth_soc: unregister net_devices in case of probe failure
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk_eth_soc: unregister net_devices in case of probe failure
If register_netdev() fails for one of the MTK_MAX_DEVS devices in
mtk_probe(), the error path jumps to err_deinit_ppe, skipping
mtk_unreg_dev(). The previously registered net_devices are then freed by
mtk_free_dev() while still in NETREG_REGISTERED state, hitting the
BUG_ON(dev->reg_state != NETREG_UNREGISTERED).
Route the register_netdev() failure to err_unreg_netdev so the net_devices
registered so far are properly unregistered before being freed.
sctp: avoid livelock while updating retransmit path
In the Linux kernel, the following vulnerability has been resolved:
sctp: avoid livelock while updating retransmit path
sctp_assoc_update_retran_path() can loop forever when every remaining
transport, including retran_path, is SCTP_UNCONFIRMED: the state check
runs before the wraparound test, so the loop cannot observe that it has
completed a full pass.
Fix this by considering a transport only when it is not UNCONFIRMED,
then checking whether the walk has returned to retran_path. This makes
the full-pass termination independent of the transport state while
preserving the existing fallback selection semantics.
Also restore the NULL guard a
net: usb: catc: bound the RX packet length in catc_rx_done()
In the Linux kernel, the following vulnerability has been resolved:
net: usb: catc: bound the RX packet length in catc_rx_done()
catc_rx_done() walks a multi-packet URB, reading a two-byte length from
each packet header. Its bound, pkt_len > urb->actual_length, ignores the
header offset and compares against the whole transfer rather than the
bytes left from pkt_start, so a crafted packet header makes
skb_copy_to_linear_data() read past the buffer.
A length below ETH_HLEN is also accepted, including zero, and
eth_type_trans() then reads a MAC header from the uninitialised tailroom
of a shorter skb. The is_f5u011 branch takes its length stra
net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget
hfsc_classify() applies the "filter may only point downwards" level check
only when the filter result carries no bound class. A filter created with
a flowid gets res.class set once at bind time, so the check never runs for
it during classification. hfsc_adjust_levels() can later raise a class's
level without revalidating existing bindings, leaving two binds that were
each legal at bind time pointing at each other; the classify walk then
bounces between two interior classes forever with the qdisc l
drm/virtio: fix object leak when drm_gem_handle_create() fails
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix object leak when drm_gem_handle_create() fails
virtio_gpu_gem_create() owns the reference taken by
virtio_gpu_object_create(). On the drm_gem_handle_create() error path it
calls drm_gem_object_release() instead of dropping that reference.
drm_gem_object_release() is the inverse of drm_gem_object_init() and does
not touch the reference count or call obj->funcs->free(), so it is only
correct as the last step of a destructor, as in
virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1
with no remaining reference, so virtio_gpu_free_object() ne
drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()
virtio_gpu_resource_create_ioctl() calls drm_gem_object_release() on the
drm_gem_handle_create() error path instead of dropping the reference it
owns, so obj->funcs->free() never runs and the virtio_gpu_object, its
pages and sg table, the resource id and the host-side resource are
leaked.
Use drm_gem_object_put() instead.
drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()
virtio_gpu_resource_create_blob_ioctl() calls drm_gem_object_release() on
both the virtio_gpu_resource_assign_uuid() and drm_gem_handle_create()
error paths instead of dropping the reference it owns, so
obj->funcs->free() never runs and the virtio_gpu_object, the resource id
and the host-side resource are leaked.
Use drm_gem_object_put() instead.
drm/virtio: release the GEM object on virtio_gpu_vram_create() errors
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: release the GEM object on virtio_gpu_vram_create() errors
virtio_gpu_vram_create() frees the object with a bare kfree(vram) on
both error paths after drm_gem_private_object_init() has run, and on the
second one after drm_gem_create_mmap_offset() has linked obj->vma_node
into the device's VMA offset manager. The freed object stays in that
interval tree, so a later lookup or insertion walks freed memory, and
the dma_resv and gpuva lock are never destroyed.
Call drm_gem_object_release() before kfree() on both paths.
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach
When the Exynos DSI driver was generalized into samsung-dsim, the TE
GPIO acquisition was switched from gpiod_get_optional() to
devm_gpiod_get_optional() while keeping the matching gpiod_put() calls.
That combination is wrong for a managed descriptor.
However, dropping the puts and keeping the managed get is also wrong:
samsung_dsim_register_te_irq() runs from the DSI host attach callback,
and host detach/reattach can happen without destroying the device that
owns the managed action. A second attach would then
Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough
Fix multiple out-of-bounds reads in Bluetooth BNEP frame processing:
1. In bnep_rx_frame() and bnep_ctrl_frame() (net/bluetooth/bnep/core.c),
use pskb_may_pull() to verify the BNEP header, control type byte,
filter count, and extension headers exist before reading them, and
return 0 after handling BNEP_CONTROL instead of falling through to
Ethernet frame submission when no extension headers follow.
2. In bnep_net_xmit() (net/bluetooth/bnep/netdev.c), verify skb->len >=
ETH
bpf: Reject non-negative offsets in stack_slot_obj_get_spi()
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject non-negative offsets in stack_slot_obj_get_spi()
bpf_get_spi() computes (-off - 1) / BPF_REG_SIZE using C division,
which truncates toward zero. For off == 0, this produces spi 0, the
same index used by the valid stack slot at fp-8.
stack_slot_obj_get_spi() currently checks alignment and the resulting
spi bounds, but does not reject the non-negative offset itself. It can
therefore validate a PTR_TO_STACK register holding fp+0 against an
iterator stored at fp-8 even though the runtime receives the actual fp+0
pointer. An effectful iterator kfunc can then interpr
ipv6: Prevent rt6_insert_exception() for dying fib6_info.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Prevent rt6_insert_exception() for dying fib6_info.
Before the cited commit, fib6_nh_flush_exceptions() always set
from->exception_bucket_flushed = 1 under rt6_exception_lock to
prevent rt6_insert_exception() from inserting a new exception
for a dying fib6_info.
The flag was replaced with the FIB6_EXCEPTION_BUCKET_FLUSHED
bit stored in nh->rt6i_exception_bucket.
The problem is that now the bit is only set when the bucket
is not NULL and fib6_nh_flush_exceptions() is called from
fib6_nh_release() after fib6_ref has already reached zero.
If rt6_insert_exception() is
net: usb: sr9700: include receive overhead in the length check
In the Linux kernel, the following vulnerability has been resolved:
net: usb: sr9700: include receive overhead in the length check
The receive fixup subtracts the Ethernet CRC from the reported packet
length, but compares that payload length against the whole remaining
receive buffer. The following copy starts after the three-byte header,
and the cursor advance consumes both that header and the four-byte CRC.
Require the payload to fit after SR_RX_OVERHEAD before copying it or
advancing to the next packet. The loop already ensures that the
remaining buffer is larger than the overhead, so the subtraction is
safe.
The issue was found by our
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
tg3: clean up PHYLIB resources on probe failure
In the Linux kernel, the following vulnerability has been resolved:
tg3: clean up PHYLIB resources on probe failure
tg3_get_invariants() can register an MDIO bus and connect a PHY for
USE_PHYLIB devices. If tg3_init_one() later fails, its common error path
releases the mappings and netdev without undoing those PHYLIB resources.
Disconnect the PHY and unregister the MDIO bus before the remaining
teardown. Guard PHY cleanup with USE_PHYLIB to match tg3_phy_init(), and
call tg3_mdio_fini() unconditionally to match tg3_mdio_init(). The existing
IS_CONNECTED and MDIOBUS_INITED flags make both helpers safe when
initialization only completed part
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
s390/debug: Fix NULL pointer dereference in debug_info_copy()
In the Linux kernel, the following vulnerability has been resolved:
s390/debug: Fix NULL pointer dereference in debug_info_copy()
When debug_register_static() fails, it clears areas, active_pages and
active_entries but leaves the area bounds unchanged. Copying such an
area, either by opening its view file or via debug_dump(), makes
debug_info_copy() dereference the NULL pointers.
Skip the copy loop when the source has no areas.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bounds check for skb-backed dynptrs
The skb_pointer_if_linear() function checks whether a
memory region of length len starting at offset off into
the skb is in the linear area, and returns a pointer to
the region if so. The check currently subtracts between
skb_headlen and offset of the check, and since skb_headlen
is unsigned the subtraction can underflow. This causes the
bounds check to spuriously pass and generate an arbitrary
pointer of the form *(skb->data + off).
The only user of this helper is currently skb-backed BPF
dynptr code. Returning the wrong pointe
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_sock context code generation
Currently, the ctx access code reads the rx_queue_mapping
field with either a 4-byte or 2-byte load. The rest of the bits
in the register are marked known zero by the verifier. However,
the emitted ctx access code places in the register on certain
the special value (-1) using BPF_MOV_IMM64, which gets sign-extended
to turn on all the bits in the register. By shifting this value right,
the program ends up with a value at runtime above what the verifier
assumes is possible.
Fix this by ensuring the read value is as wide as the assume
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject pkt arguments in mutating subprogs
The verifier tracks changes in how PTR_TO_PACKET registers'
bounds are modified across subprog boundaries. PTR_TO_PACKET
registers are actually passed as PTR_TO_MEM, which is assumed
valid for the entire call. This is not the case with packet memory,
where a pskb_* call may invalidate its memory region.
Reject BPF code that passes PTR_TO_PACKET pointers to subprogs that
may mutate a packet. We cannot pass the pointer as a true PTR_TO_PACKET
because we would also need to somehow pass the PTR_TO_PACKET_META
or PTR_TO_PACKET_END
bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc
sock_map_alloc() only rejects max_entries == 0 and otherwise allows any
u32 value. sock_map_free() then walks the sks[] array with a signed int
iterator:
int i;
for (i = 0; i < stab->map.max_entries; i++)
struct sock **psk = &stab->sks[i];
When a SOCKMAP is created with max_entries = 0xffffffff (UINT_MAX), the
allocation of 32 GiB can succeed on large-memory hosts. During free the
counter reaches 0x80000000, wraps to INT_MIN, is sign-extended by movslq
and turned into a ~16 GiB negative offset from stab->s
sctp: hold asoc or transport before mod_timer() in timer handlers
In the Linux kernel, the following vulnerability has been resolved:
sctp: hold asoc or transport before mod_timer() in timer handlers
Take the association or transport reference before rearming a timer in the
timer handlers.
The existing code calls mod_timer() before taking the reference needed by
the rearmed timer without holding the sock lock. This creates a race with
timer cleanup: if the timer is deleted after mod_timer() returns but before
the reference is taken, the cleanup path can drop the timer's reference and
destroy the transport or association. The timer handler then takes a
reference on the already freed object and eventually