KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
In the Linux kernel, the following vulnerability has been resolved:
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
kvm_io_bus_get_dev() returns a device that is only matched by the
address, and nothing else. This can cause a lifetime issue if
the matched device is not the expected type, as by the time
the caller can introspect the object, it might be gone (the srcu
lock having been dropped).
Given that there is only a single user of this helper, the simplest
option is to move the locking responsibility to the caller, which
can keep the srcu lock held for as long as it wants.
Note that this aligns with other kvm_io_bus*
fbdev: metronomefb: fix potential memory leak in metronomefb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: metronomefb: fix potential memory leak in metronomefb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().
fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().
fbdev: hecubafb: fix potential memory leak in hecubafb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: hecubafb: fix potential memory leak in hecubafb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()
The function radeonfb_pci_register() allocates memory for modelist
(by calling radeon_check_modes() which calls fb_add_videomode()).
The memory is appended to info->modelist, but is not freed in subsequent
error paths. Fix this by calling fb_destroy_modelist().
fbdev: i740fb: fix potential memory leak in i740fb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: i740fb: fix potential memory leak in i740fb_probe()
In i740fb_probe(), the memory allocated in fb_videomode_to_modelist()
for modelist is not freed in the error paths. Fix that by calling
fb_destroy_modelist().
fbdev: s3fb: fix potential memory leak in s3_pci_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: s3fb: fix potential memory leak in s3_pci_probe()
In s3_pci_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() is not freed in subsequent error paths.
Fix that by calling fb_destroy_modelist()
fbdev: uvesafb: fix potential memory leak in uvesafb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: uvesafb: fix potential memory leak in uvesafb_probe()
Due to an incorrect goto label, memory allocated for modedb and modelist
in uvesafb_vbe_init() is not freed in some error paths. Fix this by
updating the goto label.
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
In tdfxfb_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not
freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
The memory allocated for modelist in fb_videomode_to_modelist() is not
freed in the subsequent error path.
Fix that by calling fb_destroy_modelist()
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()
In nvidiafb_probe(), the memory allocated for modelist in
nvidia_set_fbinfo() is not freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().
fbdev: tridentfb: fix potential memory leak in trident_pci_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: tridentfb: fix potential memory leak in trident_pci_probe()
In trident_pci_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() is not freed in subsequent error paths.
Fix that by calling fb_destroy_modelist().
ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get
The ipc_control_data buffer is allocated as kzalloc(max_size), where
max_size covers the entire struct sof_ipc_ctrl_data including its
flexible array payload. However, the bounds checks in bytes_ext_put
and _bytes_ext_get compared user data lengths against max_size
directly, ignoring that cdata->data sits at an offset of
sizeof(struct sof_ipc_ctrl_data) bytes into the allocation.
This allowed writing up to sizeof(struct sof_ipc_ctrl_data) bytes past
the end of the heap buffer from unprivileged userspace via th
ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control
In snd_sof_update_control(), firmware-provided cdata->num_elems is
checked against local_cdata->data->size but never against the actual
allocation size. If local_cdata->data->size was previously set to an
inconsistent value, the memcpy could write past the allocated buffer.
Add a bounds check to ensure num_elems fits within the available space
in the ipc_control_data allocation before copying.
ASoC: mediatek: mt8192: Check runtime resume during probe
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8192: Check runtime resume during probe
The MT8192 AFE probe enables runtime PM temporarily while reinitializing
the regmap cache from hardware, but it uses pm_runtime_get_sync()
without checking the return value. If runtime resume fails, probe keeps
going without the device necessarily being accessible, and
pm_runtime_get_sync() may leave the PM usage count incremented.
The regmap_reinit_cache() failure path also returns before dropping the
temporary PM reference and before clearing pm_runtime_bypass_reg_ctl.
Use pm_runtime_resume_and_get() so resume fa
ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback
When q6apm_free_fragments() is called it frees rx_data.buf/tx_data.buf
and sets them to NULL under graph->lock. A late DSP buffer-done response
can race with this: graph_callback() passes the !graph->ar_graph guard
(not yet NULL), acquires the lock, but then dereferences a now-NULL buf
pointer to read buf[token].phys, crashing at virtual address 0x10.
Add a NULL check for buf inside the mutex-protected section in both the
write-done (DATA_CMD_RSP_WR_SH_MEM_EP_DATA_BUFFER_DONE_V2) and
read-done (DATA_CMD_RSP_
netfilter: xt_cluster: reject template conntracks in hash match
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_cluster: reject template conntracks in hash match
xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully
initialized conntrack and passes it to xt_cluster_hash().
This causes a state confusion bug when the raw table CT target attaches
a template conntrack to skb->_nfct before normal conntrack processing.
Templates carry IPS_TEMPLATE status but do not have a valid tuple for
hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the
zeroed l3num field.
Reject template conntracks before hashing them. This matches existing
netfilter handling
netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst
The br_netfilter fake rtable is embedded in struct net_bridge and is
attached to bridged packets with skb_dst_set_noref(). If such a packet is
queued to NFQUEUE, __nf_queue() upgrades that fake dst with
skb_dst_force().
At that point the queued skb can hold a real dst reference after bridge
teardown has started. The problem is not that every bridged packet needs
its own dst reference. The problem is that NFQUEUE can keep the bridge
private fake dst alive after unregister begins.
Fix this by keeping the br
netfilter: nft_fib: reject fib expression on the netdev egress hook
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_fib: reject fib expression on the netdev egress hook
A fib expression in a netdev egress base chain dereferences nft_in(pkt),
NULL on the transmit path, causing a NULL pointer dereference at eval.
nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook
numbers are a separate enum that aliases them (NF_NETDEV_EGRESS ==
NF_INET_LOCAL_IN), so an egress chain passes validation and then faults.
Add nft_fib_netdev_validate() that limits each result/flag to the netdev
hook where the device it reads exists: the input-device cases (OIF,
OIFNAME, ADDR
netfilter: nf_conntrack_sip: validate skb_dst() before accessing it
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: validate skb_dst() before accessing it
tc ingress and openvswitch do not guarantee routing information to be
available. These subsystems use the conntrack helper infrastructure, and
the SIP helper relies on the skb_dst() to be present if
sip_external_media is set to 1 (which is disabled by default as a module
parameter).
This effectively disables the sip_external_media toggle for these
subsystems without resulting in a crash.