| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
When QoS is disabled, the queue priority value will not map to the correct
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
is disabled to prevent trying to stop/wake a non-existent queue and failing
to stop/wake the actual queue instantiated.
Log of issue before change (with kernel parameter qos=0):
[ +5.112651] ------------[ cut here ]------------
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
[ +0.000001] CS: 0010 DS: 0
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
iio: core: fix memleak in iio_device_register_sysfs
When iio_device_register_sysfs_group() fails, we should
free iio_dev_opaque->chan_attr_group.attrs to prevent
potential memleak. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
It is preferable to exit through the out: label because
internal debugging functions are located there. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix oob in ntfs_listxattr
The length of name cannot exceed the space occupied by ea. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: fix race during shadow creation
Right now it is possible to see gmap->private being zero in
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
fact that we add gmap->private == kvm after creation:
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page)
{
[...]
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
if (IS_ERR(gmap))
return PTR_ERR(gmap);
gmap->private = vcpu->kvm;
Let children inherit the private field of the parent. |
| In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
modifies jsk->filters while receiving packets.
Following trace was seen on affected system:
==================================================================
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
print_report+0xd3/0x620
? kasan_complete_mode_report_info+0x7d/0x200
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
kasan_report+0xc2/0x100
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
__asan_load4+0x84/0xb0
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
j1939_sk_recv+0x20b/0x320 [can_j1939]
? __kasan_check_write+0x18/0x20
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
? j1939_simple_recv+0x69/0x280 [can_j1939]
? j1939_ac_recv+0x5e/0x310 [can_j1939]
j1939_can_recv+0x43f/0x580 [can_j1939]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
? raw_rcv+0x42/0x3c0 [can_raw]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
can_rcv_filter+0x11f/0x350 [can]
can_receive+0x12f/0x190 [can]
? __pfx_can_rcv+0x10/0x10 [can]
can_rcv+0xdd/0x130 [can]
? __pfx_can_rcv+0x10/0x10 [can]
__netif_receive_skb_one_core+0x13d/0x150
? __pfx___netif_receive_skb_one_core+0x10/0x10
? __kasan_check_write+0x18/0x20
? _raw_spin_lock_irq+0x8c/0xe0
__netif_receive_skb+0x23/0xb0
process_backlog+0x107/0x260
__napi_poll+0x69/0x310
net_rx_action+0x2a1/0x580
? __pfx_net_rx_action+0x10/0x10
? __pfx__raw_spin_lock+0x10/0x10
? handle_irq_event+0x7d/0xa0
__do_softirq+0xf3/0x3f8
do_softirq+0x53/0x80
</IRQ>
<TASK>
__local_bh_enable_ip+0x6e/0x70
netif_rx+0x16b/0x180
can_send+0x32b/0x520 [can]
? __pfx_can_send+0x10/0x10 [can]
? __check_object_size+0x299/0x410
raw_sendmsg+0x572/0x6d0 [can_raw]
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
? apparmor_socket_sendmsg+0x2f/0x40
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
sock_sendmsg+0xef/0x100
sock_write_iter+0x162/0x220
? __pfx_sock_write_iter+0x10/0x10
? __rtnl_unlock+0x47/0x80
? security_file_permission+0x54/0x320
vfs_write+0x6ba/0x750
? __pfx_vfs_write+0x10/0x10
? __fget_light+0x1ca/0x1f0
? __rcu_read_unlock+0x5b/0x280
ksys_write+0x143/0x170
? __pfx_ksys_write+0x10/0x10
? __kasan_check_read+0x15/0x20
? fpregs_assert_state_consistent+0x62/0x70
__x64_sys_write+0x47/0x60
do_syscall_64+0x60/0x90
? do_syscall_64+0x6d/0x90
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x79/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 348:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_alloc_info+0x1f/0x30
__kasan_kmalloc+0xb5/0xc0
__kmalloc_node_track_caller+0x67/0x160
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 349:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_free_info+0x2f/0x50
__kasan_slab_free+0x12e/0x1c0
__kmem_cache_free+0x1b9/0x380
kfree+0x7a/0x120
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8 |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: just wait for more data to be available on the socket
A short read may occur while reading the message footer from the
socket. Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data(). The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.
However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client. The sparse-read
state machine assumes that it's a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.
To determine whether read_partial_sparse_msg_data() should bail, let's
reuse cursor->total_resid. Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data. And then osd_sparse_read() could continue where it left off.
[ idryomov: changelog ] |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix disable_otg_wa logic
[Why]
When switching to another HDMI mode, we are unnecesarilly
disabling/enabling FIFO causing both HPO and DIG registers to be set at
the same time when only HPO is supposed to be set.
This can lead to a system hang the next time we change refresh rates as
there are cases when we don't disable OTG/FIFO but FIFO is enabled when
it isn't supposed to be.
[How]
Removing the enable/disable FIFO entirely. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix lock dependency warning with srcu
======================================================
WARNING: possible circular locking dependency detected
6.5.0-kfd-yangp #2289 Not tainted
------------------------------------------------------
kworker/0:2/996 is trying to acquire lock:
(srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0
but task is already holding lock:
((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at:
process_one_work+0x211/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x88/0x4f0
svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]
svm_range_set_attr+0xd6/0x14c0 [amdgpu]
kfd_ioctl+0x1d1/0x630 [amdgpu]
__x64_sys_ioctl+0x88/0xc0
-> #2 (&info->lock#2){+.+.}-{3:3}:
__mutex_lock+0x99/0xc70
amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]
restore_process_helper+0x22/0x80 [amdgpu]
restore_process_worker+0x2d/0xa0 [amdgpu]
process_one_work+0x29b/0x560
worker_thread+0x3d/0x3d0
-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}:
__flush_work+0x88/0x4f0
__cancel_work_timer+0x12c/0x1c0
kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]
__mmu_notifier_release+0xad/0x240
exit_mmap+0x6a/0x3a0
mmput+0x6a/0x120
do_exit+0x322/0xb90
do_group_exit+0x37/0xa0
__x64_sys_exit_group+0x18/0x20
do_syscall_64+0x38/0x80
-> #0 (srcu){.+.+}-{0:0}:
__lock_acquire+0x1521/0x2510
lock_sync+0x5f/0x90
__synchronize_srcu+0x4f/0x1a0
__mmu_notifier_release+0x128/0x240
exit_mmap+0x6a/0x3a0
mmput+0x6a/0x120
svm_range_deferred_list_work+0x19f/0x350 [amdgpu]
process_one_work+0x29b/0x560
worker_thread+0x3d/0x3d0
other info that might help us debug this:
Chain exists of:
srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
sync(srcu); |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix an NULL dereference bug
The issue here is when this is called from ntfs_load_attr_list(). The
"size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
the result is zero. This means that the kmalloc will succeed by
returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
Oops on the next line. |
| In the Linux kernel, the following vulnerability has been resolved:
sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
The original code puts flush_work() before timer_shutdown_sync()
in switch_drv_remove(). Although we use flush_work() to stop
the worker, it could be rescheduled in switch_timer(). As a result,
a use-after-free bug can occur. The details are shown below:
(cpu 0) | (cpu 1)
switch_drv_remove() |
flush_work() |
... | switch_timer // timer
| schedule_work(&psw->work)
timer_shutdown_sync() |
... | switch_work_handler // worker
kfree(psw) // free |
| psw->state = 0 // use
This patch puts timer_shutdown_sync() before flush_work() to
mitigate the bugs. As a result, the worker and timer will be
stopped safely before the deallocate operations. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with
the ad7091r-base driver. Those drivers declared iio events for notifying
user space when ADC readings fall bellow the thresholds of low limit
registers or above the values set in high limit registers.
However, to configure iio events and their thresholds, a set of callback
functions must be implemented and those were not present until now.
The consequence of trying to configure ad7091r-5 events without the
proper callback functions was a null pointer dereference in the kernel
because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write
event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move
those from the ad7091r-5 driver the base driver so they can be reused
when support for ad7091r-2/-4/-8 be added. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately. |
| In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path. This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng. The resulting page fault triggers a recursive read
which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user. |
| In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of
PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from
loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the
full transition table.
Also document in the ABI that this function can return -EFBIG error. |
| In the Linux kernel, the following vulnerability has been resolved:
drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment
PTR_ERR() returns -ENODEV when thermal-zones are undefined, and we need
-ENODEV as the right value for comparison.
Otherwise, tz->type is NULL when thermal-zones is undefined, resulting
in the following error:
[ 12.290030] CPU 1 Unable to handle kernel paging request at virtual address fffffffffffffff1, era == 900000000355f410, ra == 90000000031579b8
[ 12.302877] Oops[#1]:
[ 12.305190] CPU: 1 PID: 181 Comm: systemd-udevd Not tainted 6.6.0-rc7+ #5385
[ 12.312304] pc 900000000355f410 ra 90000000031579b8 tp 90000001069e8000 sp 90000001069eba10
[ 12.320739] a0 0000000000000000 a1 fffffffffffffff1 a2 0000000000000014 a3 0000000000000001
[ 12.329173] a4 90000001069eb990 a5 0000000000000001 a6 0000000000001001 a7 900000010003431c
[ 12.337606] t0 fffffffffffffff1 t1 54567fd5da9b4fd4 t2 900000010614ec40 t3 00000000000dc901
[ 12.346041] t4 0000000000000000 t5 0000000000000004 t6 900000010614ee20 t7 900000000d00b790
[ 12.354472] t8 00000000000dc901 u0 54567fd5da9b4fd4 s9 900000000402ae10 s0 900000010614ec40
[ 12.362916] s1 90000000039fced0 s2 ffffffffffffffed s3 ffffffffffffffed s4 9000000003acc000
[ 12.362931] s5 0000000000000004 s6 fffffffffffff000 s7 0000000000000490 s8 90000001028b2ec8
[ 12.362938] ra: 90000000031579b8 thermal_add_hwmon_sysfs+0x258/0x300
[ 12.386411] ERA: 900000000355f410 strscpy+0xf0/0x160
[ 12.391626] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 12.397898] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 12.403678] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
[ 12.409859] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 12.415882] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 12.415907] BADV: fffffffffffffff1
[ 12.415911] PRID: 0014a000 (Loongson-64bit, Loongson-2K1000)
[ 12.415917] Modules linked in: loongson2_thermal(+) vfat fat uio_pdrv_genirq uio fuse zram zsmalloc
[ 12.415950] Process systemd-udevd (pid: 181, threadinfo=00000000358b9718, task=00000000ace72fe3)
[ 12.415961] Stack : 0000000000000dc0 54567fd5da9b4fd4 900000000402ae10 9000000002df9358
[ 12.415982] ffffffffffffffed 0000000000000004 9000000107a10aa8 90000001002a3410
[ 12.415999] ffffffffffffffed ffffffffffffffed 9000000107a11268 9000000003157ab0
[ 12.416016] 9000000107a10aa8 ffffff80020fc0c8 90000001002a3410 ffffffffffffffed
[ 12.416032] 0000000000000024 ffffff80020cc1e8 900000000402b2a0 9000000003acc000
[ 12.416048] 90000001002a3410 0000000000000000 ffffff80020f4030 90000001002a3410
[ 12.416065] 0000000000000000 9000000002df6808 90000001002a3410 0000000000000000
[ 12.416081] ffffff80020f4030 0000000000000000 90000001002a3410 9000000002df2ba8
[ 12.416097] 00000000000000b4 90000001002a34f4 90000001002a3410 0000000000000002
[ 12.416114] ffffff80020f4030 fffffffffffffff0 90000001002a3410 9000000002df2f30
[ 12.416131] ...
[ 12.416138] Call Trace:
[ 12.416142] [<900000000355f410>] strscpy+0xf0/0x160
[ 12.416167] [<90000000031579b8>] thermal_add_hwmon_sysfs+0x258/0x300
[ 12.416183] [<9000000003157ab0>] devm_thermal_add_hwmon_sysfs+0x50/0xe0
[ 12.416200] [<ffffff80020cc1e8>] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal]
[ 12.416232] [<9000000002df6808>] platform_probe+0x68/0x140
[ 12.416249] [<9000000002df2ba8>] really_probe+0xc8/0x3c0
[ 12.416269] [<9000000002df2f30>] __driver_probe_device+0x90/0x180
[ 12.416286] [<9000000002df3058>] driver_probe_device+0x38/0x160
[ 12.416302] [<9000000002df33a8>] __driver_attach+0xa8/0x200
[ 12.416314] [<9000000002deffec>] bus_for_each_dev+0x8c/0x120
[ 12.416330] [<9000000002df198c>] bus_add_driver+0x10c/0x2a0
[ 12.416346] [<9000000002df46b4>] driver_register+0x74/0x160
[ 12.416358] [<90000000022201a4>] do_one_initcall+0x84/0x220
[ 12.416372] [<90000000022f3ab8>] do_init_module+0x58/0x2c0
[
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: scomp - fix req->dst buffer overflow
The req->dst buffer size should be checked before copying from the
scomp_scratch->dst to avoid req->dst buffer overflow problem. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: sdio: Honor the host max_req_size in the RX path
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes
with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth
combo card. The error he observed is identical to what has been fixed
in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST
bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem.
Lukas found that disabling or limiting RX aggregation works around the
problem for some time (but does not fully fix it). In the following
discussion a few key topics have been discussed which have an impact on
this problem:
- The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller
which prevents DMA transfers. Instead all transfers need to go through
the controller SRAM which limits transfers to 1536 bytes
- rtw88 chips don't split incoming (RX) packets, so if a big packet is
received this is forwarded to the host in it's original form
- rtw88 chips can do RX aggregation, meaning more multiple incoming
packets can be pulled by the host from the card with one MMC/SDIO
transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH
register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will
be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation
and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)
Use multiple consecutive reads in rtw_sdio_read_port() and limit the
number of bytes which are copied by the host from the card in one
MMC/SDIO transfer. This allows receiving a buffer that's larger than
the hosts max_req_size (number of bytes which can be transferred in
one MMC/SDIO transfer). As a result of this the skb_over_panic error
is gone as the rtw88 driver is now able to receive more than 1536 bytes
from the card (either because the incoming packet is larger than that
or because multiple packets have been aggregated).
In case of an receive errors (-EILSEQ has been observed by Lukas) we
need to drain the remaining data from the card's buffer, otherwise the
card will return corrupt data for the next rtw_sdio_read_port() call. |
| In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.
Task A | Task B
------------------+------------------
mmget_not_zero() |
| do_exit()
| exit_mm()
| mmput()
mmput() |
exit_mmap() |
remove_vma() |
fput() |
In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in
the corresponding mm->async_put_work WQ instead of Task A. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Check mailbox/SMT channel for consistency
On reception of a completion interrupt the shared memory area is accessed
to retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.
When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.
Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait
for the reply to the new request starts.
It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.
This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.
Add a consistency check to validate such condition in the A2P ISR. |
