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

    Laurentiu Palcu
     

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

    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

    Gaurav Jain
     
  • 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

    Gaurav Jain
     
  • 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

    Jacky Bai
     

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

    Pankaj Gupta
     

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

    Liu Ying
     
  • 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 FIFO

    It 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

    Laurentiu Palcu
     
  • 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 89

    The 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

    Li Jun
     

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

    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)

    Ryusuke Konishi
     
  • 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/0xcd

    Fixes: 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)

    Kuniyuki Iwashima
     
  • 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/43169

    Workqueue: 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)

    Maxim Mikityanskiy
     
  • 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 1

    Triger 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 channel

    The 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/0x30

    Freed 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/0x30

    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/0xcd

    Second 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/0xcd

    Fixes: 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)

    Zhengchao Shao
     
  • 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)

    Maxime Coquelin
     
  • 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)

    Jan Kara
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Shunsuke Mie
     
  • 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)

    Shunsuke Mie
     
  • 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)

    Cameron Gutman
     
  • 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)

    Pavel Rojtberg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     
  • 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)

    Johannes Berg
     

07 Nov, 2022

5 commits

  • 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

    Ioana Ciornei
     
  • 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: bbe75af7b092 ("arm64: dts: ls1088a: add external MDIO device nodes")
    Signed-off-by: Ioana Ciornei

    Ioana Ciornei
     
  • 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: 6e1b8fae892d ("arm64: dts: lx2160a: add emdio1 node")
    Fixes: 5705b9dcda57 ("arm64: dts: lx2160a: add emdio2 node")
    Signed-off-by: Ioana Ciornei

    Ioana Ciornei
     
  • In order to make the underneath API easier to change in the future,
    prevent users from dereferencing fwnode from struct device.
    Instead, use the specific dev_fwnode() API for that.

    Signed-off-by: zhaoxiao
    Signed-off-by: David S. Miller
    (cherry picked from commit 105b0468d7b2e6779a188a83b7e128368acb8a1d)

    zhaoxiao
     
  • When compiling with -Wformat, clang emits the following warning:

    drivers/net/ethernet/freescale/xgmac_mdio.c:243:22: warning: format
    specifies type 'unsigned char' but the argument has type 'int'
    [-Wformat]
    phy_id, dev_addr, regnum);
    ^~~~~~
    ./include/linux/dev_printk.h:163:47: note: expanded from macro 'dev_dbg'
    dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
    ~~~ ^~~~~~~~~~~
    ./include/linux/dev_printk.h:129:34: note: expanded from macro 'dev_printk'
    _dev_printk(level, dev, fmt, ##__VA_ARGS__); \
    ~~~ ^~~~~~~~~~~

    The types of these arguments are unconditionally defined, so this patch
    updates the format character to the correct ones for ints and unsigned
    ints.

    Link: https://github.com/ClangBuiltLinux/linux/issues/378
    Signed-off-by: Bill Wendling
    Link: https://lore.kernel.org/r/20220316213114.2352352-1-morbo@google.com
    Signed-off-by: Jakub Kicinski
    (cherry picked from commit c011072c90353814a9d8e2b3cd111e77ae8601ed)

    Bill Wendling