| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: iaa - Fix nr_cpus < nr_iaa case
If nr_cpus < nr_iaa, the calculated cpus_per_iaa will be 0, which
causes a divide-by-0 in rebalance_wq_table().
Make sure cpus_per_iaa is 1 in that case, and also in the nr_iaa == 0
case, even though cpus_per_iaa is never used if nr_iaa == 0, for
paranoia. |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: qcom: at803x: fix kernel panic with at8031_probe
On reworking and splitting the at803x driver, in splitting function of
at803x PHYs it was added a NULL dereference bug where priv is referenced
before it's actually allocated and then is tried to write to for the
is_1000basex and is_fiber variables in the case of at8031, writing on
the wrong address.
Fix this by correctly setting priv local variable only after
at803x_probe is called and actually allocates priv in the phydev struct. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau
Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP
DisplayPort 1.2 MST hub (the same regression does not appear when using
a Cable Matters DisplayPort 1.4 MST hub). Trace:
divide error: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206
RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020
R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a
R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010
FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0
Call Trace:
<TASK>
? show_regs+0x6d/0x80
? die+0x37/0xa0
? do_trap+0xd4/0xf0
? do_error_trap+0x71/0xb0
? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
? exc_divide_error+0x3a/0x70
? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
? asm_exc_divide_error+0x1b/0x20
? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
nv50_msto_atomic_check+0xda/0x120 [nouveau]
drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
drm_atomic_check_only+0x668/0xb20 [drm]
? drm_connector_list_iter_next+0x86/0xc0 [drm]
drm_atomic_commit+0x58/0xd0 [drm]
? __pfx___drm_printfn_info+0x10/0x10 [drm]
drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
drm_connector_property_set_ioctl+0x3b/0x60 [drm]
drm_ioctl_kernel+0xb9/0x120 [drm]
drm_ioctl+0x2d0/0x550 [drm]
? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
nouveau_drm_ioctl+0x61/0xc0 [nouveau]
__x64_sys_ioctl+0xa0/0xf0
do_syscall_64+0x76/0x140
? do_syscall_64+0x85/0x140
? do_syscall_64+0x85/0x140
entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7f4a1cd1a94f
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
RSP: 002b:00007ffd2f1df520 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f
RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f
RBP: 00000000c01064ab R08: 000056347932deb8 R09: 000056347a7d99c0
R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220
R13: 000000000000000f R14: 0000563479d9f3f0 R15: 0000000000000000
</TASK>
Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed
The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the
corresponding ttm_resource_manager is not allocated.
This leads to a crash when trying to read from this file.
Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file
only when the corresponding ttm_resource_manager is allocated.
crash> bt
PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep"
#0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3
#1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a
#2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1
#3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1
#4 [ffffb954506b3c70] no_context at ffffffffb2a7e913
#5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c
#6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887
#7 [ffffb954506b3d40] page_fault at ffffffffb360116e
[exception RIP: ttm_resource_manager_debug+0x11]
RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246
RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940
RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000
RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000
R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff
R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm]
#9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3
RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985
RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003
RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000
R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003
ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/vma: Fix UAF on destroy against retire race
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
[161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0
...
[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1
[161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
[161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]
[161.360592] RIP: 0010:debug_print_object+0x80/0xb0
...
[161.361347] debug_object_free+0xeb/0x110
[161.361362] i915_active_fini+0x14/0x130 [i915]
[161.361866] release_references+0xfe/0x1f0 [i915]
[161.362543] i915_vma_parked+0x1db/0x380 [i915]
[161.363129] __gt_park+0x121/0x230 [i915]
[161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]
That has been tracked down to be happening when another thread is
deactivating the VMA inside __active_retire() helper, after the VMA's
active counter has been already decremented to 0, but before deactivation
of the VMA's object is reported to the object debugging tool.
We could prevent from that race by serializing i915_active_fini() with
__active_retire() via ref->tree_lock, but that wouldn't stop the VMA from
being used, e.g. from __i915_vma_retire() called at the end of
__active_retire(), after that VMA has been already freed by a concurrent
i915_vma_destroy() on return from the i915_active_fini(). Then, we should
rather fix the issue at the VMA level, not in i915_active.
Since __i915_vma_parked() is called from __gt_park() on last put of the
GT's wakeref, the issue could be addressed by holding the GT wakeref long
enough for __active_retire() to complete before that wakeref is released
and the GT parked.
I believe the issue was introduced by commit d93939730347 ("drm/i915:
Remove the vma refcount") which moved a call to i915_active_fini() from
a dropped i915_vma_release(), called on last put of the removed VMA kref,
to i915_vma_parked() processing path called on last put of a GT wakeref.
However, its visibility to the object debugging tool was suppressed by a
bug in i915_active that was fixed two weeks later with commit e92eb246feb9
("drm/i915/active: Fix missing debug object activation").
A VMA associated with a request doesn't acquire a GT wakeref by itself.
Instead, it depends on a wakeref held directly by the request's active
intel_context for a GT associated with its VM, and indirectly on that
intel_context's engine wakeref if the engine belongs to the same GT as the
VMA's VM. Those wakerefs are released asynchronously to VMA deactivation.
Fix the issue by getting a wakeref for the VMA's GT when activating it,
and putting that wakeref only after the VMA is deactivated. However,
exclude global GTT from that processing path, otherwise the GPU never goes
idle. Since __i915_vma_retire() may be called from atomic contexts, use
async variant of wakeref put. Also, to avoid circular locking dependency,
take care of acquiring the wakeref before VM mutex when both are needed.
v7: Add inline comments with justifications for:
- using untracked variants of intel_gt_pm_get/put() (Nirmoy),
- using async variant of _put(),
- not getting the wakeref in case of a global GTT,
- always getting the first wakeref outside vm->mutex.
v6: Since __i915_vma_active/retire() callbacks are not serialized, storing
a wakeref tracking handle inside struct i915_vma is not safe, and
there is no other good place for that. Use untracked variants of
intel_gt_pm_get/put_async().
v5: Replace "tile" with "GT" across commit description (Rodrigo),
-
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected. As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete. But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
Reported by: xingwei lee <xrivendell7@gmail.com> |
| In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in port "disable" sysfs attribute
The show and store callback routines for the "disable" sysfs attribute
file in port.c acquire the device lock for the port's parent hub
device. This can cause problems if another process has locked the hub
to remove it or change its configuration:
Removing the hub or changing its configuration requires the
hub interface to be removed, which requires the port device
to be removed, and device_del() waits until all outstanding
sysfs attribute callbacks for the ports have returned. The
lock can't be released until then.
But the disable_show() or disable_store() routine can't return
until after it has acquired the lock.
The resulting deadlock can be avoided by calling
sysfs_break_active_protection(). This will cause the sysfs core not
to wait for the attribute's callback routine to return, allowing the
removal to proceed. The disadvantage is that after making this call,
there is no guarantee that the hub structure won't be deallocated at
any moment. To prevent this, we have to acquire a reference to it
first by calling hub_get(). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: fix double-free issue in tcpm_port_unregister_pd()
When unregister pd capabilitie in tcpm, KASAN will capture below double
-free issue. The root cause is the same capabilitiy will be kfreed twice,
the first time is kfreed by pd_capabilities_release() and the second time
is explicitly kfreed by tcpm_port_unregister_pd().
[ 3.988059] BUG: KASAN: double-free in tcpm_port_unregister_pd+0x1a4/0x3dc
[ 3.995001] Free of addr ffff0008164d3000 by task kworker/u16:0/10
[ 4.001206]
[ 4.002712] CPU: 2 PID: 10 Comm: kworker/u16:0 Not tainted 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53
[ 4.012402] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 4.017569] Workqueue: events_unbound deferred_probe_work_func
[ 4.023456] Call trace:
[ 4.025920] dump_backtrace+0x94/0xec
[ 4.029629] show_stack+0x18/0x24
[ 4.032974] dump_stack_lvl+0x78/0x90
[ 4.036675] print_report+0xfc/0x5c0
[ 4.040289] kasan_report_invalid_free+0xa0/0xc0
[ 4.044937] __kasan_slab_free+0x124/0x154
[ 4.049072] kfree+0xb4/0x1e8
[ 4.052069] tcpm_port_unregister_pd+0x1a4/0x3dc
[ 4.056725] tcpm_register_port+0x1dd0/0x2558
[ 4.061121] tcpci_register_port+0x420/0x71c
[ 4.065430] tcpci_probe+0x118/0x2e0
To fix the issue, this will remove kree() from tcpm_port_unregister_pd(). |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Add some bounds checking to firmware data
Smatch complains about "head->full_size - head->header_size" can
underflow. To some extent, we're always going to have to trust the
firmware a bit. However, it's easy enough to add a check for negatives,
and let's add a upper bounds check as well. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix several DMA buffer leaks
Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of
these buffers are never dealloced. Some of them can be deallocated
right after GSP-RM is initialized, but the rest need to stay until the
driver unloads.
Also futher bullet-proof these objects by poisoning the buffer and
clearing the nvkm_gsp_mem object when it is deallocated. Poisoning
the buffer should trigger an error (or crash) from GSP-RM if it tries
to access the buffer after we've deallocated it, because we were wrong
about when it is safe to deallocate.
Finally, change the mem->size field to a size_t because that's the same
type that dma_alloc_coherent expects. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC. |
| In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
A recent DRM series purporting to simplify support for "transparent
bridges" and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.
This has manifested itself as the display subsystem occasionally failing
to initialise and NULL-pointer dereferences during boot of machines like
the Lenovo ThinkPad X13s.
Specifically, the dp-hpd bridge is currently registered before all
resources have been acquired which means that it can also be
deregistered on probe deferrals.
In the meantime there is a race window where the new aux bridge driver
(or PHY driver previously) may have looked up the dp-hpd bridge and
stored a (non-reference-counted) pointer to the bridge which is about to
be deallocated.
When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:
dp -> aux -> dp-hpd (freed)
which may, for example, result in the freed bridge failing to attach:
[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16
or a NULL-pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
...
Call trace:
drm_bridge_attach+0x70/0x1a8 [drm]
drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
drm_bridge_attach+0x80/0x1a8 [drm]
dp_bridge_init+0xa8/0x15c [msm]
msm_dp_modeset_init+0x28/0xc4 [msm]
The DRM bridge implementation is clearly fragile and implicitly built on
the assumption that bridges may never go away. In this case, the fix is
to move the bridge registration in the pmic_glink_altmode driver to
after all resources have been looked up.
Incidentally, with the new dp-hpd bridge implementation, which registers
child devices, this is also a requirement due to a long-standing issue
in driver core that can otherwise lead to a probe deferral loop (see
commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).
[DB: slightly fixed commit message by adding the word 'commit'] |
| In the Linux kernel, the following vulnerability has been resolved:
perf: RISCV: Fix panic on pmu overflow handler
(1 << idx) of int is not desired when setting bits in unsigned long
overflowed_ctrs, use BIT() instead. This panic happens when running
'perf record -e branches' on sophgo sg2042.
[ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 273.320851] Oops [#1]
[ 273.323179] Modules linked in:
[ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9
[ 273.332521] Hardware name: Sophgo Mango (DT)
[ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e
[ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0
[ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978
[ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70
[ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000
[ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015
[ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a
[ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0
[ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210
[ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098
[ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca
[ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8
[ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d
[ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee
[ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36
[ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e
[ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74
[ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92
[ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783
[ 273.477921] ---[ end trace 0000000000000000 ]---
[ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
do_sys_name_to_handle fs/fhandle.c:73 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
do_sys_name_to_handle fs/fhandle.c:39 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem. |
| In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 |
| In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between bd_link_disk_holder and partition scan
'open_mutex' of gendisk is used to protect open/close block devices. But
in bd_link_disk_holder(), it is used to protect the creation of symlink
between holding disk and slave bdev, which introduces some issues.
When bd_link_disk_holder() is called, the driver is usually in the process
of initialization/modification and may suspend submitting io. At this
time, any io hold 'open_mutex', such as scanning partitions, can cause
deadlocks. For example, in raid:
T1 T2
bdev_open_by_dev
lock open_mutex [1]
...
efi_partition
...
md_submit_bio
md_ioctl mddev_syspend
-> suspend all io
md_add_new_disk
bind_rdev_to_array
bd_link_disk_holder
try lock open_mutex [2]
md_handle_request
-> wait mddev_resume
T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume
mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.
Fix it by introducing a local mutex 'blk_holder_mutex' to replace
'open_mutex'. |
| In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
This patch is against CVE-2023-6270. The description of cve is:
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
`struct net_device`, and a use-after-free can be triggered by racing
between the free on the struct and the access through the `skbtxq`
global queue. This could lead to a denial of service condition or
potential code execution.
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
code is finished. But the net_device ifp will still be used in
later tx()->dev_queue_xmit() in kthread. Which means that the
dev_put(ifp) should NOT be called in the success path of skb
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
use-after-free because the net_device is freed.
This patch removed the dev_put(ifp) in the success path in
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
[<69954f45>] __sys_sendmsg+0x64/0xa8
unreferenced object 0xce087000 (size 1024):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<9a993714>] __kmalloc_track_caller+0x230/0x600
[<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
[<a2c61343>] __alloc_skb+0xa0/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
observed on interface registration error path, or simply by
removing the module/unbinding device from driver:
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
==================================================================
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
Read of size 4 at addr c54d1ce8 by task sh/86
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x58
dump_stack_lvl from print_report+0x154/0x500
print_report from kasan_report+0xac/0xd8
kasan_report from wilc_netdev_cleanup+0x508/0x5cc
wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
wilc_bus_remove from spi_remove+0x8c/0xac
spi_remove from device_release_driver_internal+0x434/0x5f8
device_release_driver_internal from unbind_store+0xbc/0x108
unbind_store from kernfs_fop_write_iter+0x398/0x584
kernfs_fop_write_iter from vfs_write+0x728/0xf88
vfs_write from ksys_write+0x110/0x1e4
ksys_write from ret_fast_syscall+0x0/0x1c
[...]
Allocated by task 1:
kasan_save_track+0x30/0x5c
__kasan_kmalloc+0x8c/0x94
__kmalloc_node+0x1cc/0x3e4
kvmalloc_node+0x48/0x180
alloc_netdev_mqs+0x68/0x11dc
alloc_etherdev_mqs+0x28/0x34
wilc_netdev_ifc_init+0x34/0x8ec
wilc_cfg80211_init+0x690/0x910
wilc_bus_probe+0xe0/0x4a0
spi_probe+0x158/0x1b0
really_probe+0x270/0xdf4
__driver_probe_device+0x1dc/0x580
driver_probe_device+0x60/0x140
__driver_attach+0x228/0x5d4
bus_for_each_dev+0x13c/0x1a8
bus_add_driver+0x2a0/0x608
driver_register+0x24c/0x578
do_one_initcall+0x180/0x310
kernel_init_freeable+0x424/0x484
kernel_init+0x20/0x148
ret_from_fork+0x14/0x28
Freed by task 86:
kasan_save_track+0x30/0x5c
kasan_save_free_info+0x38/0x58
__kasan_slab_free+0xe4/0x140
kfree+0xb0/0x238
device_release+0xc0/0x2a8
kobject_put+0x1d4/0x46c
netdev_run_todo+0x8fc/0x11d0
wilc_netdev_cleanup+0x1e4/0x5cc
wilc_bus_remove+0xc8/0xec
spi_remove+0x8c/0xac
device_release_driver_internal+0x434/0x5f8
unbind_store+0xbc/0x108
kernfs_fop_write_iter+0x398/0x584
vfs_write+0x728/0xf88
ksys_write+0x110/0x1e4
ret_fast_syscall+0x0/0x1c
[...]
David Mosberger-Tan initial investigation [1] showed that this
use-after-free is due to netdevice unregistration during vif list
traversal. When unregistering a net device, since the needs_free_netdev has
been set to true during registration, the netdevice object is also freed,
and as a consequence, the corresponding vif object too, since it is
attached to it as private netdevice data. The next occurrence of the loop
then tries to access freed vif pointer to the list to move forward in the
list.
Fix this use-after-free thanks to two mechanisms:
- navigate in the list with list_for_each_entry_safe, which allows to
safely modify the list as we go through each element. For each element,
remove it from the list with list_del_rcu
- make sure to wait for RCU grace period end after each vif removal to make
sure it is safe to free the corresponding vif too (through
unregister_netdev)
Since we are in a RCU "modifier" path (not a "reader" path), and because
such path is expected not to be concurrent to any other modifier (we are
using the vif_mutex lock), we do not need to use RCU list API, that's why
we can benefit from list_for_each_entry_safe.
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/ |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
[<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0
[<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0
[<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50
[<ffffffff99805872>] really_probe+0xe2/0x480
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
[<ffffffff99804822>] bus_add_driver+0x112/0x210
[<ffffffff99807245>] driver_register+0x55/0x100
[<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
[<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470
[<ffffffff99b231f6>] kernel_init+0x16/0x1b0
[<ffffffff99042e6d>] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it. |
