| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when
setup_instance() fails with an error code. Fix that by freeing the urb
before freeing the hw structure. Also change the error paths to use the
goto ladder style.
Compile tested only. Issue found using a prototype static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
smack: fix bug: unprivileged task can create labels
If an unprivileged task is allowed to relabel itself
(/smack/relabel-self is not empty),
it can freely create new labels by writing their
names into own /proc/PID/attr/smack/current
This occurs because do_setattr() imports
the provided label in advance,
before checking "relabel-self" list.
This change ensures that the "relabel-self" list
is checked before importing the label. |
| In the Linux kernel, the following vulnerability has been resolved:
posix-timers: Prevent RT livelock in itimer_delete()
itimer_delete() has a retry loop when the timer is concurrently expired. On
non-RT kernels this just spin-waits until the timer callback has completed,
except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORK
enabled.
In that case and on RT kernels the existing task could live lock when
preempting the task which does the timer delivery.
Replace spin_unlock() with an invocation of timer_wait_running() to handle
it the same way as the other retry loops in the posix timer code. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fix memory leak in drm_client_target_cloned
dmt_mode is allocated and never freed in this function.
It was found with the ast driver, but most drivers using generic fbdev
setup are probably affected.
This fixes the following kmemleak report:
backtrace:
[<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]
[<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]
[<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]
[<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
[<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
[<00000000063a69aa>] drm_client_register+0x169/0x240 [drm]
[<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]
[<00000000987f19bb>] local_pci_probe+0xdc/0x180
[<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0
[<0000000000b85301>] process_one_work+0x8b7/0x1540
[<000000003375b17c>] worker_thread+0x70a/0xed0
[<00000000b0d43cd9>] kthread+0x29f/0x340
[<000000008d770833>] ret_from_fork+0x1f/0x30
unreferenced object 0xff11000333089a00 (size 128): |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: fix possible memory leak in ibmebus_bus_init()
If device_register() returns error in ibmebus_bus_init(), name of kobject
which is allocated in dev_set_name() called in device_add() is leaked.
As comment of device_add() says, it should call put_device() to drop
the reference count that was set in device_initialize() when it fails,
so the name can be freed in kobject_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix memory leak in rx_desc and tx_desc
Currently when ath12k_dp_cc_desc_init() is called we allocate
memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during
descriptor cleanup rx_descs and tx_descs memory is not freed.
This is cause of memory leak. These allocated memory should be
freed in ath12k_dp_cc_cleanup.
In ath12k_dp_cc_desc_init(), we can save base address of rx_descs
and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and
tx_descs memory using their base address.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: pv: fix index value of replaced ASCE
The index field of the struct page corresponding to a guest ASCE should
be 0. When replacing the ASCE in s390_replace_asce(), the index of the
new ASCE should also be set to 0.
Having the wrong index might lead to the wrong addresses being passed
around when notifying pte invalidations, and eventually to validity
intercepts (VM crash) if the prefix gets unmapped and the notifier gets
called with the wrong address. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix MSDU buffer types handling in RX error path
Currently, packets received on the REO exception ring from
unassociated peers are of MSDU buffer type, while the driver expects
link descriptor type packets. These packets are not parsed further due
to a return check on packet type in ath12k_hal_desc_reo_parse_err(),
but the associated skb is not freed. This may lead to kernel
crashes and buffer leaks.
Hence to fix, update the RX error handler to explicitly drop
MSDU buffer type packets received on the REO exception ring.
This prevents further processing of invalid packets and ensures
stability in the RX error handling path.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: anysee: fix null-ptr-deref in anysee_master_xfer
In anysee_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach anysee_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
[hverkuil: add spaces around +] |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: aead - Fix reqsize handling
Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")
introduced cra_reqsize field in crypto_alg struct to replace type
specific reqsize fields. It looks like this was introduced specifically
for ahash and acomp from the commit description as subsequent commits
add necessary changes in these alg frameworks.
However, this is being recommended for use in all crypto algs
instead of setting reqsize using crypto_*_set_reqsize(). Using
cra_reqsize in aead algorithms, hence, causes memory corruptions and
crashes as the underlying functions in the algorithm framework have not
been updated to set the reqsize properly from cra_reqsize. [1]
Add proper set_reqsize calls in the aead init function to properly
initialize reqsize for these algorithms in the framework.
[1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/iommu: Fix notifiers being shared by PCI and VIO buses
fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
PCI and VIO buses. struct notifier_block is a linked list node, so this
causes any notifiers later registered to either bus type to also be
registered to the other since they share the same node.
This causes issues in (at least) the vgaarb code, which registers a
notifier for PCI buses. pci_notify() ends up being called on a vio
device, converted with to_pci_dev() even though it's not a PCI device,
and finally makes a bad access in vga_arbiter_add_pci_device() as
discovered with KASAN:
BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00
Read of size 4 at addr c000000264c26fdc by task swapper/0/1
Call Trace:
dump_stack_lvl+0x1bc/0x2b8 (unreliable)
print_report+0x3f4/0xc60
kasan_report+0x244/0x698
__asan_load4+0xe8/0x250
vga_arbiter_add_pci_device+0x60/0xe00
pci_notify+0x88/0x444
notifier_call_chain+0x104/0x320
blocking_notifier_call_chain+0xa0/0x140
device_add+0xac8/0x1d30
device_register+0x58/0x80
vio_register_device_node+0x9ac/0xce0
vio_bus_scan_register_devices+0xc4/0x13c
__machine_initcall_pseries_vio_device_init+0x94/0xf0
do_one_initcall+0x12c/0xaa8
kernel_init_freeable+0xa48/0xba8
kernel_init+0x64/0x400
ret_from_kernel_thread+0x5c/0x64
Fix this by creating separate notifier_block structs for each bus type.
[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build] |
| In the Linux kernel, the following vulnerability has been resolved:
soundwire: fix enumeration completion
The soundwire subsystem uses two completion structures that allow
drivers to wait for soundwire device to become enumerated on the bus and
initialised by their drivers, respectively.
The code implementing the signalling is currently broken as it does not
signal all current and future waiters and also uses the wrong
reinitialisation function, which can potentially lead to memory
corruption if there are still waiters on the queue.
Not signalling future waiters specifically breaks sound card probe
deferrals as codec drivers can not tell that the soundwire device is
already attached when being reprobed. Some codec runtime PM
implementations suffer from similar problems as waiting for enumeration
during resume can also timeout despite the device already having been
enumerated. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()
The syzbot reported issue in __hfsplus_ext_cache_extent():
[ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990
[ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990
[ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0
[ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0
[ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0
[ 70.196959][ T9350] cont_write_begin+0x1000/0x1950
[ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130
[ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060
[ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460
[ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0
[ 70.199393][ T9350] vfs_write+0xb0f/0x14e0
[ 70.199771][ T9350] ksys_write+0x23e/0x490
[ 70.200149][ T9350] __x64_sys_write+0x97/0xf0
[ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0
[ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0
[ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.202054][ T9350]
[ 70.202279][ T9350] Uninit was created at:
[ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80
[ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0
[ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0
[ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0
[ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0
[ 70.205074][ T9350] cont_write_begin+0x1000/0x1950
[ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130
[ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060
[ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460
[ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0
[ 70.207552][ T9350] vfs_write+0xb0f/0x14e0
[ 70.207961][ T9350] ksys_write+0x23e/0x490
[ 70.208375][ T9350] __x64_sys_write+0x97/0xf0
[ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0
[ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0
[ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.210230][ T9350]
[ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5
[ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.212115][ T9350] =====================================================
[ 70.212734][ T9350] Disabling lock debugging due to kernel taint
[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ...
[ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5
[ 70.214679][ T9350] Tainted: [B]=BAD_PAGE
[ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.215999][ T9350] Call Trace:
[ 70.216309][ T9350] <TASK>
[ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0
[ 70.217025][ T9350] dump_stack+0x1e/0x30
[ 70.217421][ T9350] panic+0x502/0xca0
[ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0
[ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ...
kernel
:[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0
set ...
[ 70.221254][ T9350] ? __msan_warning+0x96/0x120
[ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990
[ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0
[ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0
[ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0
[ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950
[ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130
[ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060
[ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460
[ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0
[ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0
[ 70.228997][ T9350] ? ksys_write+0x23e/0x490
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: ac97: fix a double free in snd_ac97_controller_register()
If ac97_add_adapter() fails, put_device() is the correct way to drop
the device reference. kfree() is not required.
Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do
the cleanup.
Found by code review. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device
In case devcom allocation is failed, mlx5 is always freeing the priv.
However, this priv might have been allocated by a different thread,
and freeing it might lead to use-after-free bugs.
Fix it by freeing the priv only in case it was allocated by the
running thread. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()
Klocwork reported warning of rport maybe NULL and will be dereferenced.
rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.
Check valid rport returned by fc_bsg_to_rport(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe
of_phy_find_device() return device node with refcount incremented.
Call put_device() to relese it when not needed anymore. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix assertion of exclop condition when starting balance
Balance as exclusive state is compatible with paused balance and device
add, which makes some things more complicated. The assertion of valid
states when starting from paused balance needs to take into account two
more states, the combinations can be hit when there are several threads
racing to start balance and device add. This won't typically happen when
the commands are started from command line.
Scenario 1: With exclusive_operation state == BTRFS_EXCLOP_NONE.
Concurrently adding multiple devices to the same mount point and
btrfs_exclop_finish executed finishes before assertion in
btrfs_exclop_balance, exclusive_operation will changed to
BTRFS_EXCLOP_NONE state which lead to assertion failed:
fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE ||
fs_info->exclusive_operation == BTRFS_EXCLOP_DEV_ADD,
in fs/btrfs/ioctl.c:456
Call Trace:
<TASK>
btrfs_exclop_balance+0x13c/0x310
? memdup_user+0xab/0xc0
? PTR_ERR+0x17/0x20
btrfs_ioctl_add_dev+0x2ee/0x320
btrfs_ioctl+0x9d5/0x10d0
? btrfs_ioctl_encoded_write+0xb80/0xb80
__x64_sys_ioctl+0x197/0x210
do_syscall_64+0x3c/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Scenario 2: With exclusive_operation state == BTRFS_EXCLOP_BALANCE_PAUSED.
Concurrently adding multiple devices to the same mount point and
btrfs_exclop_balance executed finish before the latter thread execute
assertion in btrfs_exclop_balance, exclusive_operation will changed to
BTRFS_EXCLOP_BALANCE_PAUSED state which lead to assertion failed:
fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE ||
fs_info->exclusive_operation == BTRFS_EXCLOP_DEV_ADD ||
fs_info->exclusive_operation == BTRFS_EXCLOP_NONE,
fs/btrfs/ioctl.c:458
Call Trace:
<TASK>
btrfs_exclop_balance+0x240/0x410
? memdup_user+0xab/0xc0
? PTR_ERR+0x17/0x20
btrfs_ioctl_add_dev+0x2ee/0x320
btrfs_ioctl+0x9d5/0x10d0
? btrfs_ioctl_encoded_write+0xb80/0xb80
__x64_sys_ioctl+0x197/0x210
do_syscall_64+0x3c/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
An example of the failed assertion is below, which shows that the
paused balance is also needed to be checked.
root@syzkaller:/home/xsk# ./repro
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
Failed to add device /dev/vda, errno 14
[ 416.611428][ T7970] BTRFS info (device loop0): fs_info exclusive_operation: 0
Failed to add device /dev/vda, errno 14
[ 416.613973][ T7971] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.615456][ T7972] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.617528][ T7973] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.618359][ T7974] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.622589][ T7975] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.624034][ T7976] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.626420][ T7977] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.627643][ T7978] BTRFS info (device loop0): fs_info exclusive_operation: 3
Failed to add device /dev/vda, errno 14
[ 416.629006][ T7979] BTRFS info (device loop0): fs_info exclusive_operation: 3
[ 416.630298][ T7980] BTRFS info (device loop0): fs_info exclusive_operation: 3
Fai
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net: fix stack overflow when LRO is disabled for virtual interfaces
When the virtual interface's feature is updated, it synchronizes the
updated feature for its own lower interface.
This propagation logic should be worked as the iteration, not recursively.
But it works recursively due to the netdev notification unexpectedly.
This problem occurs when it disables LRO only for the team and bonding
interface type.
team0
|
+------+------+-----+-----+
| | | | |
team1 team2 team3 ... team200
If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE
event to its own lower interfaces(team1 ~ team200).
It is worked by netdev_sync_lower_features().
So, the NETDEV_FEAT_CHANGE notification logic of each lower interface
work iteratively.
But generated NETDEV_FEAT_CHANGE event is also sent to the upper
interface too.
upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own
lower interfaces again.
lower and upper interfaces receive this event and generate this
event again and again.
So, the stack overflow occurs.
But it is not the infinite loop issue.
Because the netdev_sync_lower_features() updates features before
generating the NETDEV_FEAT_CHANGE event.
Already synchronized lower interfaces skip notification logic.
So, it is just the problem that iteration logic is changed to the
recursive unexpectedly due to the notification mechanism.
Reproducer:
ip link add team0 type team
ethtool -K team0 lro on
for i in {1..200}
do
ip link add team$i master team0 type team
ethtool -K team$i lro on
done
ethtool -K team0 lro off
In order to fix it, the notifier_ctx member of bonding/team is introduced. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix GID entry ref leak when create_ah fails
If AH create request fails, release sgid_attr to avoid GID entry
referrence leak reported while releasing GID table |
