02 Aug, 2023
2 commits
13 May, 2023
1 commit
08 May, 2023
1 commit
03 May, 2023
1 commit
16 Nov, 2022
1 commit
-
When a plane transitions from a video tiled format (G1/G2) to linear,
without performing a disable/enable sequence, the screen will go
green because the scaler for that specific channel FREEZES.The problem happens because we don't flag the DTRC channel as 'not
running' when we switch it to bypass mode. And also because, when DPR
is set up, it checks to see whether the DTRC channel is running or not
in order to properly set the addresses. But, since it finds the channel
running, it continues to use the internal DTRC ARIDs, instead of
using the actual buffer location in DDR. Hence DPR fails with an AXI
read error, which leads to scaler freezing.The solution is to properly flag the DTRC channel when switching to
bypass mode and move the dcss_dpr_addr_set() after the
dcss_plane_set_dtrc_base() is called, so that the DTRC channel is
already flagged as "not running" by the time we set the DPR addresses.Signed-off-by: Laurentiu Palcu
Reviewed-by: Liu Ying
Acked-by: Jason Liu
15 Nov, 2022
4 commits
-
Updated otp_crypto_key & otp_unique_key device tree fix up.
Earlier, device tree fix up was based on hardcoded address, but now it's
based on compatible string of crypto node:- "fsl,imx28-dcp"Problem:-
tcrypt test were failing on imx6sll platform because crypto node address
we were searching, was specific to imx6ull which doesn't exist in imx6sll.Resolution:-
Now, searching in device tree will be based on compatible string, and hence
tcrypt test (128 key size) will not fail on imx6sll platform.Fixes: c7a1385b44a ("DCP: Add AES OTP keys support")
Signed-off-by: Kshitiz Varshney -
RNG buffer is not dma coherent,
which causes coherency issue with Sentinel.Allocated a dma coherent buffer which will be passed to Sentinel rng.
After Sentinel RNG completes processing, copy the data in rng buffer.Signed-off-by: Gaurav Jain
Reviewed-by: Pankaj Gupta -
hsm rng and kernel hwrng requires
ele rng must be started before access.earlier start rng was part of kernel hwrng initialization.
hence to make the common implementation,
moving start rng code to ele mu probe.- moved ele_get_trng_state to ele_mu_probe.
- moved ele_start_rng to ele_mu_probe.Signed-off-by: Gaurav Jain
Reviewed-by: Pankaj Gupta
Reviewed-by: Varun Sethi -
As the eDMA can NOT work well on i.MX93 A0 silicon, lpuart/lpspi use
CPU mode for data transfer. when the cpuidle is enabled, the IRQ
response latency will increase, then lead to lpuart/lpspi test failure
in high baudrate mode.Enlarge the cpuidle latency setting to let cpu has less changce to enter
low powe mode state to mitigate the latency impacted for lpuart/lpspi
high baudrate mode as much as possible.this is just a workaround to partially improve the case, it can works
well most of the time. it is not a solid fix. if still meet issue in real
case on A0 silicon, user should use cpu_dma_latency setting or disable cpuidle
as needed.Signed-off-by: Jacky Bai
Reviewed-by: Peng Fan
Acked-by: Jason Liu
11 Nov, 2022
1 commit
-
Pointer variable 'struct ele_mu_device_ctx *waiting_rsp_dev',
member to the structure 'ele_mu_priv', is used to hold the
device context waiting for the response.This pointer variable continue to hold the stale context.
It is now cleaned-up to point to NULL, once response is received.
Signed-off-by: Pankaj Gupta
Reviewed-by: Gaurav Jain
Reviewed-by: Rahul Kumar Yadav
10 Nov, 2022
3 commits
-
Without this patch, the initial video_pll1 rate is 594MHz, so the pixel
clock rate of RM67199 MIPI DSI panel would derive from it and get 118.8MHz.
With that pixel clock rate, it turns out the panel fails to show weston
GUI at the first time weston GUI starts though the Linux boot logo penguins
can be shown correctly. Based on experiments, the issue can be avoided
if the panel driver does not call mipi_dsi_dcs_get_display_brightness()
in ->get_brightness() callback at the Linux boot logo penguin stage. If
the system finishes a full reboot cycle, the issue doesn't happen since
the backlight brightness won't be gotten at that boot logo stage. The
root cause of the issue is unclear. To workaround this issue, align the
pixel clock rate with the same panel's pixel clock rate on i.MX8mp EVK,
which is 115.5MHz and derived from 1.0395GHz video PLL. RM67191 MIPI DSI
panel display and ADV7535 DSI to HDMI display are ok after applying this
patch. The only impact is the refresh rate of the MIPI DSI panels would
be a little bit lower, but it aligns with i.MX8mp EVK.Reviewed-by: Sandor Yu
Signed-off-by: Liu Ying
Acked-by: Jason Liu -
When running the 'kms_atomic_transition' IGT test suite, the following
messages appear in the dmesg:[drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: wait for content shdld done timeout
[drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: FrameGen requests to read empty FIFOIt turns out that the test tries to perform various plane transitions on
the same CRTC which can lead to 2 planes having the same source module.One example of sequence that leads to the problem is the following:
1. Perform an atomic update on planes 1 and 2. The source modules
assigned will be fetchlayer-0x00 and fetchwarp-0x02. Planes 0 and
3 are assigned no FB;
2. Perform an atomic update on planes 0 an 1. The source module for the
plane-0 will be fetchlayer-0x00. However, since current_source for
plane-1 is already fetchlayer-0x00, we end up reusing it without
checking first whether it was used already or not. Hence both
plane-0 and plane-1 will use the same fetchlayer-0x00 module...So, to fix this, move the current source checks to a separate function
where we also check whether the source was not already used for a
previous plane. If it was used, fall-back to looking for the first
available module.Signed-off-by: Laurentiu Palcu
Reviewed-by: Liu Ying
Acked-by: Jason Liu -
When usb 3.0 hub connect with one USB 2.0 device and NO USB 3.0 device,
some usb hub reports endless port reset message.[ 190.324169] usb 2-1: new SuperSpeed USB device number 88 using xhci-hcd
[ 190.352834] hub 2-1:1.0: USB hub found
[ 190.356995] hub 2-1:1.0: 4 ports detected
[ 190.700056] usb 2-1: USB disconnect, device number 88
[ 192.472139] usb 2-1: new SuperSpeed USB device number 89 using xhci-hcd
[ 192.500820] hub 2-1:1.0: USB hub found
[ 192.504977] hub 2-1:1.0: 4 ports detected
[ 192.852066] usb 2-1: USB disconnect, device number 89The reason is the runtime pm state of USB2.0 port is active and
USB 3.0 port is suspend, so parent device is active state.cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb2/power/runtime_status
suspended
cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb1/power/runtime_status
active
cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/power/runtime_status
active
cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/power/runtime_status
active
So xhci_cdns3_suspend_quirk() have not called. U3 configure is not applied.
move U3 configure into host start. Reinit again in resume function in case
controller power lost during suspend.Cc: stable@vger.kernel.org 5.10
Signed-off-by: Li Jun
Signed-off-by: Frank Li
Reviewed-by: Peter Chen
Acked-by: Alexander Stein
09 Nov, 2022
25 commits
-
Commit 056d3fed3d1f ("tee: add tee_shm_register_{user,kernel}_buf()")
refactored tee_shm_register() into corresponding user and kernel space
functions named tee_shm_register_{user,kernel}_buf(). The upstream fix
commit 573ae4f13f63 ("tee: add overflow check in register_shm_helper()")
only applied to tee_shm_register_user_buf().But the stable kernel 4.19, 5.4, 5.10 and 5.15 don't have the above
mentioned tee_shm_register() refactoring commit. Hence a direct backport
wasn't possible and the fix has to be rather applied to
tee_ioctl_shm_register().Somehow the fix was correctly backported to 4.19 and 5.4 stable kernels
but the backports for 5.10 and 5.15 stable kernels were broken as fix
was applied to common tee_shm_register() function which broke its kernel
space users such as trusted keys driver.Fortunately the backport for 5.10 stable kernel was incidently fixed by:
commit 606fe84a4185 ("tee: fix memory leak in tee_shm_register()"). So
fix the backport for 5.15 stable kernel as well.Fixes: 578c349570d2 ("tee: add overflow check in register_shm_helper()")
Reported-by: Sahil Malhotra
Signed-off-by: Sumit Garg -
commit 21a87d88c2253350e115029f14fe2a10a7e6c856 upstream.
If the i_mode field in inode of metadata files is corrupted on disk, it
can cause the initialization of bmap structure, which should have been
called from nilfs_read_inode_common(), not to be called. This causes a
lockdep warning followed by a NULL pointer dereference at
nilfs_bmap_lookup_at_level().This patch fixes these issues by adding a missing sanitiy check for the
i_mode field of metadata file's inode.Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi
Reported-by: syzbot+2b32eb36c1a825b7a74c@syzkaller.appspotmail.com
Reported-by: Tetsuo Handa
Tested-by: Ryusuke Konishi
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 1e512c65b4adcdbdf7aead052f2162b079cc7f55) -
commit 3c52c6bb831f6335c176a0fc7214e26f43adbd11 upstream.
syzbot reported a memory leak [0] related to IPV6_ADDRFORM.
The scenario is that while one thread is converting an IPv6 socket into
IPv4 with IPV6_ADDRFORM, another thread calls do_ipv6_setsockopt() and
allocates memory to inet6_sk(sk)->XXX after conversion.Then, the converted sk with (tcp|udp)_prot never frees the IPv6 resources,
which inet6_destroy_sock() should have cleaned up.setsockopt(IPV6_ADDRFORM) setsockopt(IPV6_DSTOPTS)
+-----------------------+ +----------------------+
- do_ipv6_setsockopt(sk, ...)
- sockopt_lock_sock(sk) - do_ipv6_setsockopt(sk, ...)
- lock_sock(sk) ^._ called via tcpv6_prot
- WRITE_ONCE(sk->sk_prot, &tcp_prot) before WRITE_ONCE()
- xchg(&np->opt, NULL)
- txopt_put(opt)
- sockopt_release_sock(sk)
- release_sock(sk) - sockopt_lock_sock(sk)
- lock_sock(sk)
- ipv6_set_opt_hdr(sk, ...)
- ipv6_update_options(sk, opt)
- xchg(&inet6_sk(sk)->opt, opt)
^._ opt is never freed.- sockopt_release_sock(sk)
- release_sock(sk)Since IPV6_DSTOPTS allocates options under lock_sock(), we can avoid this
memory leak by testing whether sk_family is changed by IPV6_ADDRFORM after
acquiring the lock.This issue exists from the initial commit between IPV6_ADDRFORM and
IPV6_PKTOPTIONS.[0]:
BUG: memory leak
unreferenced object 0xffff888009ab9f80 (size 96):
comm "syz-executor583", pid 328, jiffies 4294916198 (age 13.034s)
hex dump (first 32 bytes):
01 00 00 00 48 00 00 00 08 00 00 00 00 00 00 00 ....H...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc include/linux/slab.h:605 [inline]
[] sock_kmalloc+0xb3/0x100 net/core/sock.c:2566
[] ipv6_renew_options+0x21e/0x10b0 net/ipv6/exthdrs.c:1318
[] ipv6_set_opt_hdr net/ipv6/ipv6_sockglue.c:354 [inline]
[] do_ipv6_setsockopt.constprop.0+0x28b7/0x4350 net/ipv6/ipv6_sockglue.c:668
[] ipv6_setsockopt+0xdf/0x190 net/ipv6/ipv6_sockglue.c:1021
[] tcp_setsockopt+0x13b/0x2620 net/ipv4/tcp.c:3789
[] __sys_setsockopt+0x239/0x620 net/socket.c:2252
[] __do_sys_setsockopt net/socket.c:2263 [inline]
[] __se_sys_setsockopt net/socket.c:2260 [inline]
[] __x64_sys_setsockopt+0xbe/0x160 net/socket.c:2260
[] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
[] entry_SYSCALL_64_after_hwframe+0x63/0xcdFixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot
Signed-off-by: Kuniyuki Iwashima
Signed-off-by: Jakub Kicinski
Signed-off-by: Meena Shanmugam
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 1401e9336bebaa6dd5a320f83bddc17619d4e3a6) -
Fix the race condition between the following two flows that run in
parallel:1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
ret_from_fork (arch/x86/entry/entry_64.S:306)
Allocated by task 43169:
kasan_save_stack (mm/kasan/common.c:39)
__kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
__alloc_skb (net/core/skbuff.c:414)
l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
process_one_work (kernel/workqueue.c:2289)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
kthread (kernel/kthread.c:376)
ret_from_fork (arch/x86/entry/entry_64.S:306)Freed by task 27920:
kasan_save_stack (mm/kasan/common.c:39)
kasan_set_track (mm/kasan/common.c:45)
kasan_set_free_info (mm/kasan/generic.c:372)
____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
slab_free_freelist_hook (mm/slub.c:1780)
kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
sock_read_iter (net/socket.c:1087)
new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
vfs_read (fs/read_write.c:482)
ksys_read (fs/read_write.c:620)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
Fixes: d2a7ac5d5d3a ("Bluetooth: Add the ERTM receive state machine")
Fixes: 4b51dae96731 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
Signed-off-by: Maxim Mikityanskiy
Signed-off-by: Luiz Augusto von Dentz
(cherry picked from commit 3aff8aaca4e36dc8b17eaa011684881a80238966) -
When l2cap_recv_frame() is invoked to receive data, and the cid is
L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
However, after a channel is created, the hold operation of the channel
is not performed. In this case, the value of channel reference counting
is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
invokes the close hook function of A2MP to release the channel. Then
l2cap_chan_unlock(chan) will trigger UAF issue.The process is as follows:
Receive data:
l2cap_data_channel()
a2mp_channel_create() --->channel ref is 2
l2cap_chan_put() --->channel ref is 1Triger event:
hci_error_reset()
hci_dev_do_close()
...
l2cap_disconn_cfm()
l2cap_conn_del()
l2cap_chan_hold() --->channel ref is 2
l2cap_chan_del() --->channel ref is 1
a2mp_chan_close_cb() --->channel ref is 0, release channel
l2cap_chan_unlock() --->UAF of channelThe detailed Call Trace is as follows:
BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
Workqueue: hci0 hci_error_reset
Call Trace:
dump_stack_lvl+0xcd/0x134
print_report.cold+0x2ba/0x719
kasan_report+0xb1/0x1e0
kasan_check_range+0x140/0x190
__mutex_unlock_slowpath+0xa6/0x5e0
l2cap_conn_del+0x404/0x7b0
l2cap_disconn_cfm+0x8c/0xc0
hci_conn_hash_flush+0x11f/0x260
hci_dev_close_sync+0x5f5/0x11f0
hci_dev_do_close+0x2d/0x70
hci_error_reset+0x9e/0x140
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
Allocated by task 7593:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0xa9/0xd0
l2cap_chan_create+0x40/0x930
amp_mgr_create+0x96/0x990
a2mp_channel_create+0x7d/0x150
l2cap_recv_frame+0x51b8/0x9a70
l2cap_recv_acldata+0xaa3/0xc00
hci_rx_work+0x702/0x1220
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30Freed by task 7593:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
____kasan_slab_free+0x167/0x1c0
slab_free_freelist_hook+0x89/0x1c0
kfree+0xe2/0x580
l2cap_chan_put+0x22a/0x2d0
l2cap_conn_del+0x3fc/0x7b0
l2cap_disconn_cfm+0x8c/0xc0
hci_conn_hash_flush+0x11f/0x260
hci_dev_close_sync+0x5f5/0x11f0
hci_dev_do_close+0x2d/0x70
hci_error_reset+0x9e/0x140
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30Last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0xbe/0xd0
call_rcu+0x99/0x740
netlink_release+0xe6a/0x1cf0
__sock_release+0xcd/0x280
sock_close+0x18/0x20
__fput+0x27c/0xa90
task_work_run+0xdd/0x1a0
exit_to_user_mode_prepare+0x23c/0x250
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x42/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcdSecond to last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0xbe/0xd0
call_rcu+0x99/0x740
netlink_release+0xe6a/0x1cf0
__sock_release+0xcd/0x280
sock_close+0x18/0x20
__fput+0x27c/0xa90
task_work_run+0xdd/0x1a0
exit_to_user_mode_prepare+0x23c/0x250
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x42/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcdFixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
Signed-off-by: Zhengchao Shao
Signed-off-by: Luiz Augusto von Dentz
(cherry picked from commit 0d0e2d032811280b927650ff3c15fe5020e82533) -
commit 46f8a29272e51b6df7393d58fc5cb8967397ef2b upstream.
If the VDUSE application provides a smaller config space
than the driver expects, the driver may use uninitialized
memory from the stack.This patch prevents it by initializing the buffer passed by
the driver to store the config value.This fix addresses CVE-2022-2308.
Cc: stable@vger.kernel.org # v5.15+
Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace")
Reviewed-by: Xie Yongji
Acked-by: Jason Wang
Signed-off-by: Maxime Coquelin
Message-Id:
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Chaitanya Kulkarni
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit dc248ddf41eab4566e95b1ee2433c8a5134ad94a) -
commit 61a1d87a324ad5e3ed27c6699dfc93218fcf3201 upstream.
The check in __ext4_read_dirblock() for block being outside of directory
size was wrong because it compared block number against directory size
in bytes. Fix it.Fixes: 65f8ea4cd57d ("ext4: check if directory block is within i_size")
CVE: CVE-2022-1184
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara
Reviewed-by: Lukas Czerner
Link: https://lore.kernel.org/r/20220822114832.1482-1-jack@suse.cz
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit dd366295d1eca557e7a9000407ec3952f691d27b) -
commit ff05d4b45dd89b922578dac497dcabf57cf771c6
When we parse a multi-BSSID element, we might point some
element pointers into the allocated nontransmitted_profile.
However, we free this before returning, causing UAF when the
relevant pointers in the parsed elements are accessed.Fix this by not allocating the scratch buffer separately but
as part of the returned structure instead, that way, there
are no lifetime issues with it.The scratch buffer introduction as part of the returned data
here is taken from MLO feature work done by Ilan.This fixes CVE-2022-42719.
Fixes: 5023b14cf4df ("mac80211: support profile split between elements")
Co-developed-by: Ilan Peer
Signed-off-by: Ilan Peer
Reviewed-by: Kees Cook
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit de124365a7d2deed22cf706583930f28d537ff0f) -
commit 8223ac199a3849257e86ec27865dc63f034b1cf1 upstream.
My previous commit 5d24828d05f3 ("mac80211: always allocate
struct ieee802_11_elems") had a few bugs and leaked the new
allocated struct in a few error cases, fix that.Fixes: 5d24828d05f3 ("mac80211: always allocate struct ieee802_11_elems")
Signed-off-by: Johannes Berg
Link: https://lore.kernel.org/r/20211001211108.9839928e42e0.Ib81ca187d3d3af7ed1bfeac2e00d08a4637c8025@changeid
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 7d998f6b7365d50a9905bf57fd28b41c7ebe8e9d) -
As the 802.11 spec evolves, we need to parse more and more
elements. This is causing the struct to grow, and we can no
longer get away with putting it on the stack.Change the API to always dynamically allocate and return an
allocated pointer that must be kfree()d later.As an alternative, I contemplated a scheme whereby we'd say
in the code which elements we needed, e.g.DECLARE_ELEMENT_PARSER(elems,
SUPPORTED_CHANNELS,
CHANNEL_SWITCH,
EXT(KEY_DELIVERY));ieee802_11_parse_elems(..., &elems, ...);
and while I think this is possible and will save us a lot
since most individual places only care about a small subset
of the elements, it ended up being a bit more work since a
lot of places do the parsing and then pass the struct to
other functions, sometimes with multiple levels.Link: https://lore.kernel.org/r/20210920154009.26caff6b5998.I05ae58768e990e611aee8eca8abefd9d7bc15e05@changeid
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit fee48f3bdd7516bb63da507213916227cf147211) -
commit 49a765d6785e99157ff5091cc37485732496864e upstream.
There's no need to parse all elements etc. just to find the
authentication challenge - use cfg80211_find_elem() instead.
This also allows us to remove WLAN_EID_CHALLENGE handling
from the element parsing entirely.Link: https://lore.kernel.org/r/20210920154009.45f9b3a15722.Ice3159ffad03a007d6154cbf1fb3a8c48489e86f@changeid
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 630060f1175676b9cb3a032767f20dbce93616c9) -
commit c6e37ed498f958254b5459253199e816b6bfc52f upstream.
We're currently returning this value, but to prepare for
returning the allocated structure, move it into there.Link: https://lore.kernel.org/r/20210920154009.479b8ebf999d.If0d4ba75ee38998dc3eeae25058aa748efcb2fc9@changeid
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 21df3a583e8e03d8f74fa2eedbcd7a2b3f5cabc1) -
commit a5b983c6073140b624f64e79fea6d33c3e4315a0 upstream.
We currently pass the entire elements to the rx_bcn_presp()
method, but only need mesh_config. Additionally, we use the
length of the elements to calculate back the entire frame's
length, but that's confusing - just pass the length of the
frame instead.Link: https://lore.kernel.org/r/20210920154009.a18ed3d2da6c.I1824b773a0fbae4453e1433c184678ca14e8df45@changeid
Signed-off-by: Johannes Berg
Cc: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 864f2d3482f4bd0c62b355e35ee8300be8ef488e) -
commit 8e30538eca016de8e252bef174beadecd64239f0 upstream.
The dma_map_single() doesn't permit zero length mapping. It causes a follow
panic.A panic was reported on arm64:
[ 60.137988] ------------[ cut here ]------------
[ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624!
[ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l
2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn
c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl
[ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237
[ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
[ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590
[ 60.213149] lr : swiotlb_map+0x88/0x1f0
[ 60.216982] sp : ffff80000a883bc0
[ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000
[ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0
[ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000
[ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000
[ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180
[ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000
[ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000
[ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001
[ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010
[ 60.291658] Call trace:
[ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590
[ 60.298629] swiotlb_map+0x88/0x1f0
[ 60.302115] dma_map_page_attrs+0x188/0x230
[ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]
[ 60.312660] __arm64_sys_ioctl+0xa8/0xf0
[ 60.316583] invoke_syscall+0x44/0x108
[ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0
[ 60.325038] do_el0_svc+0x2c/0xb8
[ 60.328351] el0_svc+0x2c/0x88
[ 60.331406] el0t_64_sync_handler+0xb8/0xc0
[ 60.335587] el0t_64_sync+0x18c/0x190
[ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)
[ 60.345344] ---[ end trace 0000000000000000 ]---To fix it, this patch adds a checking the payload length if it is zero.
Fixes: 343dc693f7b7 ("misc: pci_endpoint_test: Prevent some integer overflows")
Cc: stable
Signed-off-by: Shunsuke Mie
Link: https://lore.kernel.org/r/20220907020100.122588-2-mie@igel.co.jp
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit e5ebcbb4f967af2083d409271aaf7c7d8351603f) -
commit 3e42deaac06567c7e86d287c305ccda24db4ae3d upstream.
Each transfer test functions have same parameter checking code. This patch
unites those to an introduced function.Signed-off-by: Shunsuke Mie
Cc: stable
Link: https://lore.kernel.org/r/20220907020100.122588-1-mie@igel.co.jp
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit cb9defecf381415f6aeb433a05a6c4374775e9d6) -
commit a17b9841152e7f4621619902b347e2cc39c32996 upstream.
Suspending and resuming the system can sometimes cause the out
URB to get hung after a reset_resume. This causes LED setting
and force feedback to break on resume. To avoid this, just drop
the reset_resume callback so the USB core rebinds xpad to the
wireless pads on resume if a reset happened.A nice side effect of this change is the LED ring on wireless
controllers is now set correctly on system resume.Cc: stable@vger.kernel.org
Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume")
Signed-off-by: Cameron Gutman
Signed-off-by: Pavel Rojtberg
Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 2c657a0cbd481eda0a6e12c45f55f03d3332223b) -
commit b382c5e37344883dc97525d05f1f6b788f549985 upstream.
This is based on multiple commits at https://github.com/paroj/xpad
Cc: stable@vger.kernel.org
Signed-off-by: Jasper Poppe
Signed-off-by: Jeremy Palmer
Signed-off-by: Ruineka
Signed-off-by: Cleber de Mattos Casali
Signed-off-by: Kyle Gospodnetich
Signed-off-by: Pavel Rojtberg
Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit db4db28fccb47a4476f2ea1fd5ea22da8f6bedde) -
commit c90b93b5b782891ebfda49d4e5da36632fefd5d1 upstream.
When updating beacon elements in a non-transmitted BSS,
also update the hidden sub-entries to the same beacon
elements, so that a future update through other paths
won't trigger a WARN_ON().The warning is triggered because the beacon elements in
the hidden BSSes that are children of the BSS should
always be the same as in the parent.Reported-by: Sönke Huster
Tested-by: Sönke Huster
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit d15bb1f6dabe1d2a4155958111bea47db72b599c) -
commit b2d03cabe2b2e150ff5a381731ea0355459be09f upstream.
If beacon protection is active but the beacon cannot be
decrypted or is otherwise malformed, we call the cfg80211
API to report this to userspace, but that uses a netdev
pointer, which isn't present for P2P-Device. Fix this to
call it only conditionally to ensure cfg80211 won't crash
in the case of P2P-Device.This fixes CVE-2022-42722.
Reported-by: Sönke Huster
Fixes: 9eaf183af741 ("mac80211: Report beacon protection failures to user space")
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 93a3a32554079432b49cf87f326607b2a2fab4f2) -
commit 1833b6f46d7e2830251a063935ab464256defe22 upstream.
If the tool on the other side (e.g. wmediumd) gets confused
about the rate, we hit a warning in mac80211. Silence that
by effectively duplicating the check here and dropping the
frame silently (in mac80211 it's dropped with the warning).Reported-by: Sönke Huster
Tested-by: Sönke Huster
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit fff244e9171b2ca692469d41c68b36607bd73ab0) -
commit bcca852027e5878aec911a347407ecc88d6fff7f upstream.
If a non-transmitted BSS shares enough information (both
SSID and BSSID!) with another non-transmitted BSS of a
different AP, then we can find and update it, and then
try to add it to the non-transmitted BSS list. We do a
search for it on the transmitted BSS, but if it's not
there (but belongs to another transmitted BSS), the list
gets corrupted.Since this is an erroneous situation, simply fail the
list insertion in this case and free the non-transmitted
BSS.This fixes CVE-2022-42721.
Reported-by: Sönke Huster
Tested-by: Sönke Huster
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 0a8ee682e4f992eccce226b012bba600bb2251e2) -
commit 0b7808818cb9df6680f98996b8e9a439fa7bcc2f upstream.
There are multiple refcounting bugs related to multi-BSSID:
- In bss_ref_get(), if the BSS has a hidden_beacon_bss, then
the bss pointer is overwritten before checking for the
transmitted BSS, which is clearly wrong. Fix this by using
the bss_from_pub() macro.- In cfg80211_bss_update() we copy the transmitted_bss pointer
from tmp into new, but then if we release new, we'll unref
it erroneously. We already set the pointer and ref it, but
need to NULL it since it was copied from the tmp data.- In cfg80211_inform_single_bss_data(), if adding to the non-
transmitted list fails, we unlink the BSS and yet still we
return it, but this results in returning an entry without
a reference. We shouldn't return it anyway if it was broken
enough to not get added there.This fixes CVE-2022-42720.
Reported-by: Sönke Huster
Tested-by: Sönke Huster
Fixes: a3584f56de1c ("cfg80211: Properly track transmitting and non-transmitting BSS")
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit bfe29873454f38eb1a511a76144ad1a4848ca176) -
commit 567e14e39e8f8c6997a1378bc3be615afca86063 upstream.
When iterating the elements here, ensure the length byte is
present before checking it to see if the entire element will
fit into the buffer.Longer term, we should rewrite this code using the type-safe
element iteration macros that check all of this.Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Reported-by: Soenke Huster
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 9e99ca59ed3976921f8891c103d503b6da3e78af) -
commit 8f033d2becc24aa6bfd2a5c104407963560caabc upstream.
Per spec, the maximum value for the MaxBSSID ('n') indicator is 8,
and the minimum is 1 since a multiple BSSID set with just one BSSID
doesn't make sense (the # of BSSIDs is limited by 2^n).Limit this in the parsing in both cfg80211 and mac80211, rejecting
any elements with an invalid value.This fixes potentially bad shifts in the processing of these inside
the cfg80211_gen_new_bssid() function later.I found this during the investigation of CVE-2022-41674 fixed by the
previous patch.Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Fixes: 78ac51f81532 ("mac80211: support multi-bssid")
Reviewed-by: Kees Cook
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 0a861bd25dad508e492c48169509d8c6b9246895) -
commit aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d upstream.
In the copy code of the elements, we do the following calculation
to reach the end of the MBSSID element:/* copy the IEs after MBSSID */
cpy_len = mbssid[1] + 2;This looks fine, however, cpy_len is a u8, the same as mbssid[1],
so the addition of two can overflow. In this case the subsequent
memcpy() will overflow the allocated buffer, since it copies 256
bytes too much due to the way the allocation and memcpy() sizes
are calculated.Fix this by using size_t for the cpy_len variable.
This fixes CVE-2022-41674.
Reported-by: Soenke Huster
Tested-by: Soenke Huster
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Reviewed-by: Kees Cook
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
(cherry picked from commit 9a8ef2030510a9d6ce86fd535b8d10720230811f)
07 Nov, 2022
1 commit
-
Up until now, the external MDIO controller frequency values relied
either on the default ones out of reset or on those setup by u-boot.
Let's just properly specify the MDC frequency in the DTS so that even
without u-boot's intervention Linux can drive the MDIO bus.Fixes: 0420dde30a90 ("arm64: dts: ls208xa: add the external MDIO nodes")
Signed-off-by: Ioana Ciornei
