- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] cifs: Fix UAF in cifs_demultiplex_thread()
by ZhaoLong Wang 09 Mar '24

09 Mar '24

From: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> mainline inclusion from mainline-v6.6-rc3 commit d527f51331cace562393a8038d870b3e9916686f category: bugfix bugzilla: 189615 CVE: CVE-2023-52572 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The UAF is because: mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------------------------- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback 1. After send request to server, wait the response until mid->mid_state != SUBMITTED; 2. Receive response from server, and set it to mid; 3. Set the mid state to RECEIVED; 4. Kill the process, the mid state already RECEIVED, get 0; 5. Handle and release the negotiate response; 6. UAF. It can be easily reproduce with add some delay in [3] - [6]. Only sync call has the problem since async call's callback is executed in cifsd process. Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely. Fixes: ec637e3ffb6b ("[CIFS] Avoid extra large buffer allocation (and memcpy) in cifs_readpages") Reviewed-by: Paulo Alcantara (SUSE) <pc(a)manguebit.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/cifs/transport.c fs/cifs/connect.c Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/cifs/cifsglob.h | 1 + fs/cifs/connect.c | 3 ++- fs/cifs/transport.c | 30 ++++++++++++++++++++---------- 3 files changed, 23 insertions(+), 11 deletions(-) diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 71c2dd0c7f03..f9abe37c549c 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -1597,6 +1597,7 @@ static inline bool is_retryable_error(int error) #define MID_RETRY_NEEDED 8 /* session closed while this request out */ #define MID_RESPONSE_MALFORMED 0x10 #define MID_SHUTDOWN 0x20 +#define MID_RESPONSE_READY 0x40 /* ready for other process handle the rsp */ /* Flags */ #define MID_WAIT_CANCELLED 1 /* Cancelled while waiting for response */ diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 4ca6fd66df03..684dbd580a27 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -1079,7 +1079,8 @@ cifs_demultiplex_thread(void *p) if (mids[i] != NULL) { mids[i]->resp_buf_size = server->pdu_size; if ((mids[i]->mid_flags & MID_WAIT_CANCELLED) && - mids[i]->mid_state == MID_RESPONSE_RECEIVED && + (mids[i]->mid_state == MID_RESPONSE_RECEIVED || + mids[i]->mid_state == MID_RESPONSE_READY) && server->ops->handle_cancelled_mid) server->ops->handle_cancelled_mid( mids[i]->resp_buf, diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c index eb76f7a59e50..fa83799b3ec0 100644 --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -46,6 +46,8 @@ void cifs_wake_up_task(struct mid_q_entry *mid) { + if (mid->mid_state == MID_RESPONSE_RECEIVED) + mid->mid_state = MID_RESPONSE_READY; wake_up_process(mid->callback_data); } @@ -561,7 +563,8 @@ wait_for_response(struct TCP_Server_Info *server, struct mid_q_entry *midQ) int error; error = wait_event_freezekillable_unsafe(server->response_q, - midQ->mid_state != MID_REQUEST_SUBMITTED); + midQ->mid_state != MID_REQUEST_SUBMITTED && + midQ->mid_state != MID_RESPONSE_RECEIVED); if (error < 0) return -ERESTARTSYS; @@ -699,7 +702,7 @@ cifs_sync_mid_result(struct mid_q_entry *mid, struct TCP_Server_Info *server) spin_lock(&GlobalMid_Lock); switch (mid->mid_state) { - case MID_RESPONSE_RECEIVED: + case MID_RESPONSE_READY: spin_unlock(&GlobalMid_Lock); return rc; case MID_RETRY_NEEDED: @@ -790,6 +793,8 @@ cifs_setup_request(struct cifs_ses *ses, struct smb_rqst *rqst) static void cifs_noop_callback(struct mid_q_entry *mid) { + if (mid->mid_state == MID_RESPONSE_RECEIVED) + mid->mid_state = MID_RESPONSE_READY; } int @@ -912,7 +917,8 @@ compound_send_recv(const unsigned int xid, struct cifs_ses *ses, midQ[i]->mid); send_cancel(ses->server, &rqst[i], midQ[i]); spin_lock(&GlobalMid_Lock); - if (midQ[i]->mid_state == MID_REQUEST_SUBMITTED) { + if (midQ[i]->mid_state == MID_REQUEST_SUBMITTED || + midQ[i]->mid_state == MID_RESPONSE_RECEIVED) { midQ[i]->mid_flags |= MID_WAIT_CANCELLED; midQ[i]->callback = DeleteMidQEntry; cancelled_mid[i] = true; @@ -938,7 +944,7 @@ compound_send_recv(const unsigned int xid, struct cifs_ses *ses, } if (!midQ[i]->resp_buf || - midQ[i]->mid_state != MID_RESPONSE_RECEIVED) { + midQ[i]->mid_state != MID_RESPONSE_READY) { rc = -EIO; cifs_dbg(FYI, "Bad MID state?\n"); goto out; @@ -1118,7 +1124,8 @@ SendReceive(const unsigned int xid, struct cifs_ses *ses, if (rc != 0) { send_cancel(ses->server, &rqst, midQ); spin_lock(&GlobalMid_Lock); - if (midQ->mid_state == MID_REQUEST_SUBMITTED) { + if (midQ->mid_state == MID_REQUEST_SUBMITTED || + midQ->mid_state == MID_RESPONSE_RECEIVED) { /* no longer considered to be "in-flight" */ midQ->callback = DeleteMidQEntry; spin_unlock(&GlobalMid_Lock); @@ -1135,7 +1142,7 @@ SendReceive(const unsigned int xid, struct cifs_ses *ses, } if (!midQ->resp_buf || !out_buf || - midQ->mid_state != MID_RESPONSE_RECEIVED) { + midQ->mid_state != MID_RESPONSE_READY) { rc = -EIO; cifs_dbg(VFS, "Bad MID state?\n"); goto out; @@ -1254,13 +1261,15 @@ SendReceiveBlockingLock(const unsigned int xid, struct cifs_tcon *tcon, /* Wait for a reply - allow signals to interrupt. */ rc = wait_event_interruptible(ses->server->response_q, - (!(midQ->mid_state == MID_REQUEST_SUBMITTED)) || + (!(midQ->mid_state == MID_REQUEST_SUBMITTED || + midQ->mid_state == MID_RESPONSE_RECEIVED)) || ((ses->server->tcpStatus != CifsGood) && (ses->server->tcpStatus != CifsNew))); /* Were we interrupted by a signal ? */ if ((rc == -ERESTARTSYS) && - (midQ->mid_state == MID_REQUEST_SUBMITTED) && + (midQ->mid_state == MID_REQUEST_SUBMITTED || + midQ->mid_state == MID_RESPONSE_RECEIVED) && ((ses->server->tcpStatus == CifsGood) || (ses->server->tcpStatus == CifsNew))) { @@ -1290,7 +1299,8 @@ SendReceiveBlockingLock(const unsigned int xid, struct cifs_tcon *tcon, if (rc) { send_cancel(ses->server, &rqst, midQ); spin_lock(&GlobalMid_Lock); - if (midQ->mid_state == MID_REQUEST_SUBMITTED) { + if (midQ->mid_state == MID_REQUEST_SUBMITTED || + midQ->mid_state == MID_RESPONSE_RECEIVED) { /* no longer considered to be "in-flight" */ midQ->callback = DeleteMidQEntry; spin_unlock(&GlobalMid_Lock); @@ -1308,7 +1318,7 @@ SendReceiveBlockingLock(const unsigned int xid, struct cifs_tcon *tcon, return rc; /* rcvd frame is ok */ - if (out_buf == NULL || midQ->mid_state != MID_RESPONSE_RECEIVED) { + if (out_buf == NULL || midQ->mid_state != MID_RESPONSE_READY) { rc = -EIO; cifs_dbg(VFS, "Bad MID state?\n"); goto out; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] EDAC/thunderx: Fix possible out-of-bounds string access
by Lu Jialin 09 Mar '24

09 Mar '24

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v4.19.306 commit 71c17ee02538802ceafc830f0736aa35b564e601 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EBW CVE: CVE-2023-52464 -------------------------------- [ Upstream commit 475c58e1a471e9b873e3e39958c64a2d278275c8 ] Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> Link: https://lore.kernel.org/r/20231122222007.3199885-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- drivers/edac/thunderx_edac.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/edac/thunderx_edac.c b/drivers/edac/thunderx_edac.c index 34be60fe6892..0fffb393415b 100644 --- a/drivers/edac/thunderx_edac.c +++ b/drivers/edac/thunderx_edac.c @@ -1133,7 +1133,7 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id) decode_register(other, OCX_OTHER_SIZE, ocx_com_errors, ctx->reg_com_int); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); for (lane = 0; lane < OCX_RX_LANES; lane++) if (ctx->reg_com_int & BIT(lane)) { @@ -1142,12 +1142,12 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id) lane, ctx->reg_lane_int[lane], lane, ctx->reg_lane_stat11[lane]); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); decode_register(other, OCX_OTHER_SIZE, ocx_lane_errors, ctx->reg_lane_int[lane]); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); } if (ctx->reg_com_int & OCX_COM_INT_CE) @@ -1217,7 +1217,7 @@ static irqreturn_t thunderx_ocx_lnk_threaded_isr(int irq, void *irq_id) decode_register(other, OCX_OTHER_SIZE, ocx_com_link_errors, ctx->reg_com_link_int); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); if (ctx->reg_com_link_int & OCX_COM_LINK_INT_UE) edac_device_handle_ue(ocx->edac_dev, 0, 0, msg); @@ -1896,7 +1896,7 @@ static irqreturn_t thunderx_l2c_threaded_isr(int irq, void *irq_id) decode_register(other, L2C_OTHER_SIZE, l2_errors, ctx->reg_int); - strncat(msg, other, L2C_MESSAGE_SIZE); + strlcat(msg, other, L2C_MESSAGE_SIZE); if (ctx->reg_int & mask_ue) edac_device_handle_ue(l2c->edac_dev, 0, 0, msg); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] EDAC/thunderx: Fix possible out-of-bounds string access
by Lu Jialin 09 Mar '24

09 Mar '24

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v4.19.306 commit 1c17ee02538802ceafc830f0736aa35b564e601 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EBW CVE: CVE-2023-52464 -------------------------------- [ Upstream commit 475c58e1a471e9b873e3e39958c64a2d278275c8 ] Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> Link: https://lore.kernel.org/r/20231122222007.3199885-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- drivers/edac/thunderx_edac.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/edac/thunderx_edac.c b/drivers/edac/thunderx_edac.c index 34be60fe6892..0fffb393415b 100644 --- a/drivers/edac/thunderx_edac.c +++ b/drivers/edac/thunderx_edac.c @@ -1133,7 +1133,7 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id) decode_register(other, OCX_OTHER_SIZE, ocx_com_errors, ctx->reg_com_int); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); for (lane = 0; lane < OCX_RX_LANES; lane++) if (ctx->reg_com_int & BIT(lane)) { @@ -1142,12 +1142,12 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id) lane, ctx->reg_lane_int[lane], lane, ctx->reg_lane_stat11[lane]); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); decode_register(other, OCX_OTHER_SIZE, ocx_lane_errors, ctx->reg_lane_int[lane]); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); } if (ctx->reg_com_int & OCX_COM_INT_CE) @@ -1217,7 +1217,7 @@ static irqreturn_t thunderx_ocx_lnk_threaded_isr(int irq, void *irq_id) decode_register(other, OCX_OTHER_SIZE, ocx_com_link_errors, ctx->reg_com_link_int); - strncat(msg, other, OCX_MESSAGE_SIZE); + strlcat(msg, other, OCX_MESSAGE_SIZE); if (ctx->reg_com_link_int & OCX_COM_LINK_INT_UE) edac_device_handle_ue(ocx->edac_dev, 0, 0, msg); @@ -1896,7 +1896,7 @@ static irqreturn_t thunderx_l2c_threaded_isr(int irq, void *irq_id) decode_register(other, L2C_OTHER_SIZE, l2_errors, ctx->reg_int); - strncat(msg, other, L2C_MESSAGE_SIZE); + strlcat(msg, other, L2C_MESSAGE_SIZE); if (ctx->reg_int & mask_ue) edac_device_handle_ue(l2c->edac_dev, 0, 0, msg); -- 2.34.1

2 1

[PATCH OLK-5.10] wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
by Yongqiang Liu 09 Mar '24

09 Mar '24

From: Pin-yen Lin <treapking(a)chromium.org> stable inclusion from stable-v5.10.198 commit 10a18c8bac7f60d32b7af22da03b66f350beee38 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AXH CVE: CVE-2023-52525 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit aef7a0300047e7b4707ea0411dc9597cba108fc8 ] Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers. Fixes: 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets") Signed-off-by: Pin-yen Lin <treapking(a)chromium.org> Acked-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Matthew Wang <matthewmwang(a)chromium.org> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://lore.kernel.org/r/20230908104308.1546501-1-treapking@chromium.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/net/wireless/marvell/mwifiex/sta_rx.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/sta_rx.c b/drivers/net/wireless/marvell/mwifiex/sta_rx.c index 3c555946cb2c..5b16e330014a 100644 --- a/drivers/net/wireless/marvell/mwifiex/sta_rx.c +++ b/drivers/net/wireless/marvell/mwifiex/sta_rx.c @@ -98,7 +98,8 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv, rx_pkt_len = le16_to_cpu(local_rx_pd->rx_pkt_length); rx_pkt_hdr = (void *)local_rx_pd + rx_pkt_off; - if (sizeof(*rx_pkt_hdr) + rx_pkt_off > skb->len) { + if (sizeof(rx_pkt_hdr->eth803_hdr) + sizeof(rfc1042_header) + + rx_pkt_off > skb->len) { mwifiex_dbg(priv->adapter, ERROR, "wrong rx packet offset: len=%d, rx_pkt_off=%d\n", skb->len, rx_pkt_off); @@ -107,12 +108,13 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv, return -1; } - if ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header, - sizeof(bridge_tunnel_header))) || - (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header, - sizeof(rfc1042_header)) && - ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP && - ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX)) { + if (sizeof(*rx_pkt_hdr) + rx_pkt_off <= skb->len && + ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header, + sizeof(bridge_tunnel_header))) || + (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header, + sizeof(rfc1042_header)) && + ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP && + ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX))) { /* * Replace the 803 header and rfc1042 header (llc/snap) with an * EthernetII header, keep the src/dst and snap_type -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 13425/21785] drivers/net/ethernet/huawei/hinic/hinic_main.c:249:23: error: implicit declaration of function 'vlan_dev_priv'; did you mean 'netdev_priv'?
by kernel test robot 09 Mar '24

09 Mar '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3d10c870b322e5d1a4f8fb923b879a0b73246157 commit: 90f09a01314abe26de1a722d1b51c351d84e1f5b [13425/21785] net/hinic: Add support for X86 Arch config: x86_64-randconfig-015-20240308 (https://download.01.org/0day-ci/archive/20240309/202403091438.ZbJbSAui-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240309/202403091438.ZbJbSAui-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403091438.ZbJbSAui-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/net/ethernet/huawei/hinic/hinic_main.c: In function 'hinic_netdev_event': >> drivers/net/ethernet/huawei/hinic/hinic_main.c:249:23: error: implicit declaration of function 'vlan_dev_priv'; did you mean 'netdev_priv'? [-Werror=implicit-function-declaration] 249 | ret = vlan_dev_priv(ndev)->real_dev; | ^~~~~~~~~~~~~ | netdev_priv >> drivers/net/ethernet/huawei/hinic/hinic_main.c:249:42: error: invalid type argument of '->' (have 'int') 249 | ret = vlan_dev_priv(ndev)->real_dev; | ^~ drivers/net/ethernet/huawei/hinic/hinic_main.c:251:49: error: invalid type argument of '->' (have 'int') 251 | ret = vlan_dev_priv(ret)->real_dev; | ^~ drivers/net/ethernet/huawei/hinic/hinic_main.c: At top level: drivers/net/ethernet/huawei/hinic/hinic_main.c:3294:6: warning: no previous prototype for 'nic_event' [-Wmissing-prototypes] 3294 | void nic_event(struct hinic_lld_dev *lld_dev, void *adapter, | ^~~~~~~~~ cc1: some warnings being treated as errors vim +249 drivers/net/ethernet/huawei/hinic/hinic_main.c edd384f682cc29 Aviad Krawczyk 2017-08-21 221 6cb2e756917d12 Xue 2019-01-31 222 #define HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT 2 6cb2e756917d12 Xue 2019-01-31 223 #define HINIC_VLAN_CLEAR_OFFLOAD (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \ 6cb2e756917d12 Xue 2019-01-31 224 NETIF_F_SCTP_CRC | NETIF_F_RXCSUM | \ 6cb2e756917d12 Xue 2019-01-31 225 NETIF_F_ALL_TSO) edd384f682cc29 Aviad Krawczyk 2017-08-21 226 6cb2e756917d12 Xue 2019-01-31 227 int hinic_netdev_event(struct notifier_block *notifier, 6cb2e756917d12 Xue 2019-01-31 228 unsigned long event, void *ptr) edd384f682cc29 Aviad Krawczyk 2017-08-21 229 { 6cb2e756917d12 Xue 2019-01-31 230 struct net_device *ndev = netdev_notifier_info_to_dev(ptr); 6cb2e756917d12 Xue 2019-01-31 231 struct net_device *real_dev, *ret; 6cb2e756917d12 Xue 2019-01-31 232 struct hinic_nic_dev *nic_dev; 6cb2e756917d12 Xue 2019-01-31 233 u16 vlan_depth; 6cb2e756917d12 Xue 2019-01-31 234 6cb2e756917d12 Xue 2019-01-31 235 if (!is_vlan_dev(ndev)) 6cb2e756917d12 Xue 2019-01-31 236 return NOTIFY_DONE; 6cb2e756917d12 Xue 2019-01-31 237 6cb2e756917d12 Xue 2019-01-31 238 dev_hold(ndev); 6cb2e756917d12 Xue 2019-01-31 239 6cb2e756917d12 Xue 2019-01-31 240 switch (event) { 6cb2e756917d12 Xue 2019-01-31 241 case NETDEV_REGISTER: 6cb2e756917d12 Xue 2019-01-31 242 real_dev = vlan_dev_real_dev(ndev); 6cb2e756917d12 Xue 2019-01-31 243 nic_dev = hinic_get_uld_dev_by_ifname(real_dev->name, 6cb2e756917d12 Xue 2019-01-31 244 SERVICE_T_NIC); 6cb2e756917d12 Xue 2019-01-31 245 if (!nic_dev) 6cb2e756917d12 Xue 2019-01-31 246 goto out; 6cb2e756917d12 Xue 2019-01-31 247 6cb2e756917d12 Xue 2019-01-31 248 vlan_depth = 1; 6cb2e756917d12 Xue 2019-01-31 @249 ret = vlan_dev_priv(ndev)->real_dev; 6cb2e756917d12 Xue 2019-01-31 250 while (is_vlan_dev(ret)) { 6cb2e756917d12 Xue 2019-01-31 251 ret = vlan_dev_priv(ret)->real_dev; 6cb2e756917d12 Xue 2019-01-31 252 vlan_depth++; 6cb2e756917d12 Xue 2019-01-31 253 } 6cb2e756917d12 Xue 2019-01-31 254 6cb2e756917d12 Xue 2019-01-31 255 if (vlan_depth == HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT) { 6cb2e756917d12 Xue 2019-01-31 256 ndev->vlan_features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 257 } else if (vlan_depth > HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT) { 6cb2e756917d12 Xue 2019-01-31 258 #ifdef HAVE_NDO_SET_FEATURES 6cb2e756917d12 Xue 2019-01-31 259 #ifdef HAVE_RHEL6_NET_DEVICE_OPS_EXT 6cb2e756917d12 Xue 2019-01-31 260 set_netdev_hw_features(ndev, 6cb2e756917d12 Xue 2019-01-31 261 get_netdev_hw_features(ndev) & 6cb2e756917d12 Xue 2019-01-31 262 (~HINIC_VLAN_CLEAR_OFFLOAD)); 6cb2e756917d12 Xue 2019-01-31 263 #else 6cb2e756917d12 Xue 2019-01-31 264 ndev->hw_features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 265 #endif 6cb2e756917d12 Xue 2019-01-31 266 #endif 6cb2e756917d12 Xue 2019-01-31 267 ndev->features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 268 } edd384f682cc29 Aviad Krawczyk 2017-08-21 269 6cb2e756917d12 Xue 2019-01-31 270 break; edd384f682cc29 Aviad Krawczyk 2017-08-21 271 6cb2e756917d12 Xue 2019-01-31 272 default: 6cb2e756917d12 Xue 2019-01-31 273 break; 6cb2e756917d12 Xue 2019-01-31 274 }; edd384f682cc29 Aviad Krawczyk 2017-08-21 275 6cb2e756917d12 Xue 2019-01-31 276 out: 6cb2e756917d12 Xue 2019-01-31 277 dev_put(ndev); edd384f682cc29 Aviad Krawczyk 2017-08-21 278 6cb2e756917d12 Xue 2019-01-31 279 return NOTIFY_DONE; edd384f682cc29 Aviad Krawczyk 2017-08-21 280 } 6cb2e756917d12 Xue 2019-01-31 281 #endif edd384f682cc29 Aviad Krawczyk 2017-08-21 282 :::::: The code at line 249 was first introduced by commit :::::: 6cb2e756917d122560e0c52f350682760d004eec net: hinic: Add NIC Layer :::::: TO: Xue <xuechaojing(a)huawei.com> :::::: CC: Xie XiuQi <xiexiuqi(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
by Li Huafei 09 Mar '24

09 Mar '24

From: Hans de Goede <hdegoede(a)redhat.com> stable inclusion from stable-v4.19.297 commit 44481b244fcaa2b895a53081d6204c574720c38c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94P85 CVE: CVE-2023-52478 --------------------------- commit dac501397b9d81e4782232c39f94f4307b137452 upstream. hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/hid/hid-logitech-hidpp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 504e8917b06f..eda8833b8c7f 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -3080,7 +3080,8 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id) /* Allow incoming packets */ hid_device_io_start(hdev); - hidpp_connect_event(hidpp); + schedule_work(&hidpp->work); + flush_work(&hidpp->work); return ret; -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: mac80211: fix potential key use-after-free
by Dong Chenchen 09 Mar '24

09 Mar '24

From: Johannes Berg <johannes.berg(a)intel.com> mainline inclusion from mainline-v5.12-rc6 commit 31db78a4923ef5e2008f2eed321811ca79e7f71b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASP CVE: CVE-2023-52530 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/cfg.c Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/cfg.c | 3 +++ net/mac80211/key.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index c6a7f1c99abc..70126518ad16 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -509,6 +509,9 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev, sta->cipher_scheme = cs; err = ieee80211_key_link(key, sdata, sta); + /* KRACK protection, shouldn't happen but just silently accept key */ + if (err == -EALREADY) + err = 0; out_unlock: mutex_unlock(&local->sta_mtx); diff --git a/net/mac80211/key.c b/net/mac80211/key.c index 6a72c33679ba..6b089594a9f3 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -843,7 +843,7 @@ int ieee80211_key_link(struct ieee80211_key *key, */ if (ieee80211_key_identical(sdata, old_key, key)) { ieee80211_key_free_unused(key); - ret = 0; + ret = -EALREADY; goto out; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] wifi: mac80211: fix potential key use-after-free
by Dong Chenchen 09 Mar '24

09 Mar '24

From: Johannes Berg <johannes.berg(a)intel.com> mainline inclusion from mainline-v5.12-rc6 commit 31db78a4923ef5e2008f2eed321811ca79e7f71b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASP CVE: CVE-2023-52530 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/cfg.c Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/cfg.c | 3 +++ net/mac80211/key.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index e46944500cfa..2201923238ed 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -457,6 +457,9 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev, sta->cipher_scheme = cs; err = ieee80211_key_link(key, sdata, sta); + /* KRACK protection, shouldn't happen but just silently accept key */ + if (err == -EALREADY) + err = 0; out_unlock: mutex_unlock(&local->sta_mtx); diff --git a/net/mac80211/key.c b/net/mac80211/key.c index 6775d6cb7d3d..017a9d2b5cec 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -681,7 +681,7 @@ int ieee80211_key_link(struct ieee80211_key *key, */ if (ieee80211_key_identical(sdata, old_key, key)) { ieee80211_key_free_unused(key); - ret = 0; + ret = -EALREADY; goto out; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v1 0/6] Fix CVE-2023-52514
by Wei Li 09 Mar '24

09 Mar '24

This series is meant to fix CVE-2023-52514, with 5 LTS patches which are depended on but not backported before. Sean Christopherson (6): x86/reboot: Force all cpus to exit VMX root if VMX is supported x86/virt: Force GIF=1 prior to disabling SVM (for reboot flows) x86/crash: Disable virt in core NMI crash handler to avoid double shootdown x86/reboot: Disable virtualization in an emergency if SVM is supported x86/reboot: Disable SVM, not just VMX, when stopping CPUs x86/reboot: VMCLEAR active VMCSes before emergency reboot arch/x86/include/asm/kexec.h | 2 - arch/x86/include/asm/reboot.h | 4 ++ arch/x86/include/asm/virtext.h | 16 ++++- arch/x86/kernel/crash.c | 47 +------------ arch/x86/kernel/reboot.c | 121 ++++++++++++++++++++++++--------- arch/x86/kernel/smp.c | 6 +- arch/x86/kvm/vmx.c | 12 +--- 7 files changed, 112 insertions(+), 96 deletions(-) -- 2.25.1

2 7

[PATCH openEuler-1.0-LTS] drm: bridge/panel: Cleanup connector on bridge detach
by Guo Mengqi 09 Mar '24

09 Mar '24

From: Paul Cercueil <paul(a)crapouillou.net> stable inclusion from stable-v5.10.37 commit ce450934a00cf896e648fde08d0bd1426653d7a2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94VOL CVE: CVE-2021-47063 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 upstream. If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable(a)vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> conflicts: drivers/gpu/drm/bridge/panel.c Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/bridge/panel.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 7cbaba213ef6..dbeaf1257668 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -92,6 +92,17 @@ static int panel_bridge_attach(struct drm_bridge *bridge) static void panel_bridge_detach(struct drm_bridge *bridge) { struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + struct drm_connector *connector = &panel_bridge->connector; + + /* + * Cleanup the connector if we know it was initialized. + * + * FIXME: This wouldn't be needed if the panel_bridge structure was + * allocated with drmm_kzalloc(). This might be tricky since the + * drm_device pointer can only be retrieved when the bridge is attached. + */ + if (connector->dev) + drm_connector_cleanup(connector); drm_panel_detach(panel_bridge->panel); } -- 2.17.1

2 1