platform/x86: dell-laptop: fix missing cleanups in init error path
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-laptop: fix missing cleanups in init error path
dell_init() initializes several resources after dell_setup_rfkill(),
including the optional touchpad LED, keyboard backlight LED, battery
hook, debugfs directory and dell-laptop notifier.
If a later LED or backlight registration fails, the error path only
tears down the battery hook and rfkill resources. This leaves the
notifier, debugfs directory, keyboard backlight LED and optional
touchpad LED registered after dell_init() returns an error.
Add the missing cleanup calls before tearing down rfkill.
i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
In the Linux kernel, the following vulnerability has been resolved:
i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic
(polling) path rejects it as -EPROTO. Worse, it returns without a
NACK+STOP: the next receive cycle has already started, so the target
keeps holding SDA and the bus stays stuck until a power cycle for
this i2c controller.
Reading I2DR to obtain the count likewise arms the next byte on the
count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly
and left the bus held.
Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->
i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()
In the Linux kernel, the following vulnerability has been resolved:
i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()
If devm_platform_get_and_ioremap_resource() returns an error,
mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to
get the error code. This results in a use-after-free.
Save the error code before freeing tmp_res.
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: fix error handling in ioctl
When gntdev_ioctl_map_grant_ref() fails to copy the operation result
back to userspace after successfully adding the mapping to the list,
the error path returns -EFAULT without releasing the reference
acquired by gntdev_alloc_map(). The mapping remains in priv->maps
with a refcount of 1, causing a memory leak and a dangling list
entry.
Additionally, gntdev_add_map() may modify map->index to avoid overlap
with existing mappings. Therefore, the index returned to userspace
must be obtained after gntdev_add_map() completes.
Fix this by
xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink
In the Linux kernel, the following vulnerability has been resolved:
xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink
xfrmi_changelink() operates on at most two netns, dev_net(dev) and the
interface link netns xi->net. They differ once the device is created in
or moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in xi->net can rewrite an interface that
lives in xi->net.
Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed.
In the Linux kernel, the following vulnerability has been resolved:
tpm: Make the TPM character devices non-seekable
The TPM character devices expose a sequential command/response
interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE
enabled.
After a command leaves a response pending, pread(fd, buf, 16, 0x1400)
passes 0x1400 as *off to tpm_common_read(). The transfer length is
bounded by response_length, but the offset is used unchecked when
forming data_buffer + *off. A sufficiently large offset therefore causes
an out-of-bounds heap read through copy_to_user() and, if the copy
succeeds, an out-of-bounds zero-write through
spi: uniphier: Fix completion initialization order before devm_request_irq()
In the Linux kernel, the following vulnerability has been resolved:
spi: uniphier: Fix completion initialization order before devm_request_irq()
The driver calls devm_request_irq() before initializing the completion
used by the interrupt handler. Because the interrupt may occur immediately
after devm_request_irq(), the handler may execute before init_completion().
This may result in calling complete() on an uninitialized completion,
causing undefined behavior. This has been observed with KASAN.
Fix this by initializing the completion before registering the IRQ.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: reject short AUTH_RECEIVE buffers
nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length
after checking only that it is nonzero and matches the transfer length.
In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF
initiator reach the fixed-size DH-HMAC-CHAP response builders with a
kmalloc() buffer shorter than the response, so nvmet_auth_success1() and
nvmet_auth_failure1() write past the allocation; both only WARN_ON the
short length and then format the message anyway.
Impact: A remote NVMe-oF initiator with access to an aut
nvmet-rdma: handle inline data with a nonzero offset
In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: handle inline data with a nonzero offset
nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset
into the per-command inline scatterlist. The bounds check admits any
offset with off + len <= inline_data_size, but the mapping still assumes
the data begins in the first inline page:
sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);
When a port is configured with inline_data_size > PAGE_SIZE (settable up
to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]
makes "PAGE_SIZE - off" underflow, so sg->length is set to
can: isotp: use unconditional synchronize_rcu() in isotp_release()
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: use unconditional synchronize_rcu() in isotp_release()
isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister()
and clears so->bound without waiting for a grace period. isotp_release()
uses so->bound to decide whether it needs to call synchronize_rcu()
before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it
skips that synchronize_rcu() and can cancel the timer while an
in-flight isotp_rcv() is still executing and about to re-arm it via
isotp_send_fc(), leading to a use-after-free timer callback on the
freed socket.
sakisho-bot rem
can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
isotp_release() looked up the bound network device via dev_get_by_index()
using the stored ifindex. During device unregistration the device is
unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier
chain runs, so a concurrent isotp_release() could find no device, skip
can_rx_unregister() entirely, and still proceed to free the socket.
Since isotp_release() had already removed itself from the isotp
notifier list at that point, isotp_notify() would never get a chance to
clean up either, leavin
can: isotp: serialize TX state transitions under so->rx_lock
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: serialize TX state transitions under so->rx_lock
The TX state machine (so->tx.state) is driven from three contexts:
sendmsg() claiming and progressing a transfer, the RX path consuming
Flow Control/echo frames, and two hrtimers timing out a stalled
transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with
hrtimer_cancel() calls made under so->rx_lock elsewhere left windows
where a frame or timer callback could act on a state that had already
moved on, corrupting an unrelated transfer.
so->rx_lock now covers the full lifecycle of a TX claim: sendmsg()
takes
can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly
synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op()
with call_rcu() and introduced the RX_NO_AUTOTIMER flag.
However, this flag check was omitted for thrtimer in the packet rx
fast-path. During BCM RX operation teardown, a concurrent RCU reader
(bcm_rx_handler) can race and re-arm thrtimer via
bcm_rx_update_and_send() after call_rcu() has been scheduled. Once
the RCU grace period elapses, bcm_op is freed. The subsequently
f
can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure
bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking
lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all
mutate both fields under that same lock. Because the lockless reads
and the locked writes are unordered with respect to each other, a
racing bcm_notify() (device unregister) or bcm_connect() (concurrent
bind on another thread sharing the socket) can make bcm_sendmsg()
observe an inconsistent combination, e.g. a stale bound=1 together
with the now-cleared ifindex=0, silent
can: bcm: add locking when updating filter and timer values
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking when updating filter and timer values
KCSAN detected a simultaneous access to timer values that can be
overwritten in bcm_rx_setup() when updating timer and filter content
while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler()
run concurrently on incoming CAN traffic.
Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter
(nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new
per-op bcm_rx_update_lock, taken with the matching scope in the RX
handlers. memcpy_from_msg() is staged into a temporary buff
can: bcm: add missing rcu list annotations and operations
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu list annotations and operations
sashiko-bot remarked the missing use of list_add_rcu() in
bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure
when bcm_proc_show() traverses the bcm_op's under rcu_read_lock().
To cover all initial settings of the bcm_op's the list_add_rcu() calls
are moved to the end of the setup code.
While at it, also fix the mirroring removal side: bcm_release() called
bcm_remove_op() - which frees the op via call_rcu() - on ops that were
still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first.
Unlink
can: bcm: extend bcm_tx_lock usage for data and timer updates
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: extend bcm_tx_lock usage for data and timer updates
Stage new CAN frame content for an existing tx op into a kmalloc()'d
buffer and validate it there, mirroring the approach already used in
bcm_rx_setup(). Only copy the validated data into op->frames while
holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler()
can no longer observe a partially updated or unvalidated frame.
Add a missing error path for memcpy_from_msg() when copying CAN frame
data from userspace.
Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup()
under op->bcm_tx
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix CAN frame rx/tx statistics
KCSAN detected a data race within the bcm_rx_handler() when two CAN frames
have been simultaneously received and processed in a single rx op by two
different CPUs.
Use atomic operations with (signed) long data types to access the
statistics in the hot path to fix the KCSAN complaint.
Additionally simplify the update and check of statistics overflow by
using the atomic operations in separate bcm_update_[rx|tx]_stats()
functions. The rx variant runs under bcm_rx_update_lock to prevent
races when resetting the two rx counters; the tx
can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()
For an rx op subscribed on all interfaces (ifindex == 0), the same op
is registered once in the shared per-netns wildcard filter list, so
bcm_rx_handler() can run concurrently on different CPUs for frames
arriving on different net devices.
op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was
taken, allowing concurrent writers to race each other - including a torn
store of the 64-bit rx_stamp on 32-bit platforms.
Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex
can: bcm: fix stale rx/tx ops after device removal
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix stale rx/tx ops after device removal
RX: an RX_SETUP update(!) for an existing op skipped can_rx_register()
unconditionally, even when a concurrent NETDEV_UNREGISTER had already
torn down its registration (op->rx_reg_dev == NULL). This silently
did not re-enable frame delivery for that updated filter. bcm_rx_setup()
now re-registers in that case, while leaving rx_ops with ifindex = 0
(all CAN devices) which never carry a tracked rx_reg_dev registered as-is.
TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving
tx_ops with an active cyclic tra