From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Marek Szyprowski <m.szyprowski@samsung.com>, Sylwester Nawrocki <snawrocki@kernel.org>, Alim Akhtar <alim.akhtar@samsung.com>, Andrzej Hajda <a.hajda@samsung.com> Subject: [RFT 2/2] i2c: s3c2410: fix possible NULL pointer deref on read message after write Date: Thu, 15 Apr 2021 11:38:03 +0200 [thread overview] Message-ID: <20210415093803.162673-2-krzysztof.kozlowski@canonical.com> (raw) In-Reply-To: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com> Interrupt handler processes multiple message write requests one after another, till the driver message queue is drained. However if driver encounters a read message without preceding START, it stops the I2C transfer as it is an invalid condition for the controller. At least the comment describes a requirement "the controller forces us to send a new START when we change direction". This stop results in clearing the message queue (i2c->msg = NULL). The code however immediately jumped back to label "retry_write" which dereferenced the "i2c->msg" making it a possible NULL pointer dereference. The Coverity analysis: 1. Condition !is_msgend(i2c), taking false branch. if (!is_msgend(i2c)) { 2. Condition !is_lastmsg(i2c), taking true branch. } else if (!is_lastmsg(i2c)) { 3. Condition i2c->msg->flags & 1, taking true branch. if (i2c->msg->flags & I2C_M_RD) { 4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL. s3c24xx_i2c_stop(i2c, -EINVAL); 5. Jumping to label retry_write. goto retry_write; All previous calls to s3c24xx_i2c_stop() in this interrupt service routine are followed by jumping to end of function (acknowledging the interrupt and returning). This seems a reasonable choice also here since message buffer was entirely emptied. Addresses-Coverity: Explicit null dereferenced Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> --- drivers/i2c/busses/i2c-s3c2410.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index ab928613afba..4d82761e1585 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -480,7 +480,10 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat) * forces us to send a new START * when we change direction */ + dev_dbg(i2c->dev, + "missing START before write->read\n"); s3c24xx_i2c_stop(i2c, -EINVAL); + break; } goto retry_write; -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Marek Szyprowski <m.szyprowski@samsung.com>, Sylwester Nawrocki <snawrocki@kernel.org>, Alim Akhtar <alim.akhtar@samsung.com>, Andrzej Hajda <a.hajda@samsung.com> Subject: [RFT 2/2] i2c: s3c2410: fix possible NULL pointer deref on read message after write Date: Thu, 15 Apr 2021 11:38:03 +0200 [thread overview] Message-ID: <20210415093803.162673-2-krzysztof.kozlowski@canonical.com> (raw) In-Reply-To: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com> Interrupt handler processes multiple message write requests one after another, till the driver message queue is drained. However if driver encounters a read message without preceding START, it stops the I2C transfer as it is an invalid condition for the controller. At least the comment describes a requirement "the controller forces us to send a new START when we change direction". This stop results in clearing the message queue (i2c->msg = NULL). The code however immediately jumped back to label "retry_write" which dereferenced the "i2c->msg" making it a possible NULL pointer dereference. The Coverity analysis: 1. Condition !is_msgend(i2c), taking false branch. if (!is_msgend(i2c)) { 2. Condition !is_lastmsg(i2c), taking true branch. } else if (!is_lastmsg(i2c)) { 3. Condition i2c->msg->flags & 1, taking true branch. if (i2c->msg->flags & I2C_M_RD) { 4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL. s3c24xx_i2c_stop(i2c, -EINVAL); 5. Jumping to label retry_write. goto retry_write; All previous calls to s3c24xx_i2c_stop() in this interrupt service routine are followed by jumping to end of function (acknowledging the interrupt and returning). This seems a reasonable choice also here since message buffer was entirely emptied. Addresses-Coverity: Explicit null dereferenced Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> --- drivers/i2c/busses/i2c-s3c2410.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index ab928613afba..4d82761e1585 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -480,7 +480,10 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat) * forces us to send a new START * when we change direction */ + dev_dbg(i2c->dev, + "missing START before write->read\n"); s3c24xx_i2c_stop(i2c, -EINVAL); + break; } goto retry_write; -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-15 9:38 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-15 9:38 [PATCH 1/2] i2c: s3c2410: simplify getting of_device_id match data Krzysztof Kozlowski 2021-04-15 9:38 ` Krzysztof Kozlowski 2021-04-15 9:38 ` Krzysztof Kozlowski [this message] 2021-04-15 9:38 ` [RFT 2/2] i2c: s3c2410: fix possible NULL pointer deref on read message after write Krzysztof Kozlowski 2021-04-15 9:45 ` [PATCH 1/2] i2c: s3c2410: simplify getting of_device_id match data Sylwester Nawrocki 2021-04-15 9:45 ` Sylwester Nawrocki 2021-04-16 23:07 ` Wolfram Sang 2021-04-16 23:07 ` Wolfram Sang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210415093803.162673-2-krzysztof.kozlowski@canonical.com \ --to=krzysztof.kozlowski@canonical.com \ --cc=a.hajda@samsung.com \ --cc=alim.akhtar@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=snawrocki@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.