From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:37316 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068AbdFRBDn (ORCPT ); Sat, 17 Jun 2017 21:03:43 -0400 Subject: Patch "[media] cec: race fix: don't return -ENONET in cec_receive()" has been added to the 4.11-stable tree To: hans.verkuil@cisco.com, gregkh@linuxfoundation.org, mchehab@s-opensource.com Cc: , From: Date: Sun, 18 Jun 2017 09:03:28 +0800 Message-ID: <1497747808215107@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled [media] cec: race fix: don't return -ENONET in cec_receive() to the 4.11-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: cec-race-fix-don-t-return-enonet-in-cec_receive.patch and it can be found in the queue-4.11 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From b94aac64a4c17c5af92f9b4ba7164c5b384d5c02 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 7 Jun 2017 12:07:51 -0300 Subject: [media] cec: race fix: don't return -ENONET in cec_receive() From: Hans Verkuil commit b94aac64a4c17c5af92f9b4ba7164c5b384d5c02 upstream. When calling CEC_RECEIVE do not check if the adapter is configured. Typically CEC_RECEIVE is called after a select() and if that indicates that there are messages in the receive queue, then you should always be able to dequeue a message. The race condition here is that a message has been received and is queued, so select() tells userspace that a message is available. But before the application calls CEC_RECEIVE the adapter is unconfigured (e.g. the HDMI cable is removed). Now select will always report that there is a message, but calling CEC_RECEIVE will always return -ENONET because the adapter is no longer configured and so will never actually dequeue the message. There is really no need for this check, and in fact the ENONET error code was never documented for CEC_RECEIVE. This may have been a left-over of old code that was never updated. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman --- drivers/media/cec/cec-api.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/drivers/media/cec/cec-api.c +++ b/drivers/media/cec/cec-api.c @@ -267,16 +267,10 @@ static long cec_receive(struct cec_adapt bool block, struct cec_msg __user *parg) { struct cec_msg msg = {}; - long err = 0; + long err; if (copy_from_user(&msg, parg, sizeof(msg))) return -EFAULT; - mutex_lock(&adap->lock); - if (!adap->is_configured && fh->mode_follower < CEC_MODE_MONITOR) - err = -ENONET; - mutex_unlock(&adap->lock); - if (err) - return err; err = cec_receive_msg(fh, &msg, block); if (err) Patches currently in stable-queue which might be from hans.verkuil@cisco.com are queue-4.11/vb2-fix-an-off-by-one-error-in-vb2_plane_vaddr.patch queue-4.11/pvrusb2-reduce-stack-usage-pvr2_eeprom_analyze.patch queue-4.11/coda-restore-original-firmware-locations.patch queue-4.11/cec-race-fix-don-t-return-enonet-in-cec_receive.patch