2022-03-17 05:23:24

by tangmeng

Subject: [PATCH] hamradio: Fix wrong assignment of 'bbc->cfg.loopback'

In file hamradio/baycom_epp.c, the baycom_setmode interface, there
is a problem with improper use of strstr.

Suppose that when modestr="noloopback", both conditions which are
'strstr(modestr,"noloopback")' and 'strstr(modestr,"loopback")'
will be true(not NULL), this lead the bc->cfg.loopback variable
will be first assigned to 0, and then reassigned to 1.

This will cause 'bc->cfg.loopback = 0' will never take effect. That
obviously violates the logic of the code, so adjust the order of
their execution to solve the problem.

Signed-off-by: Meng Tang <[email protected]>
---
drivers/net/hamradio/baycom_epp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index a03d0b474641..36e6de42ae77 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -982,10 +982,10 @@ static int baycom_setmode(struct baycom_state *bc, const char *modestr)
bc->cfg.extmodem = 0;
if (strstr(modestr,"extmodem"))
bc->cfg.extmodem = 1;
- if (strstr(modestr,"noloopback"))
- bc->cfg.loopback = 0;
if (strstr(modestr,"loopback"))
bc->cfg.loopback = 1;
+ if (strstr(modestr, "noloopback"))
+ bc->cfg.loopback = 0;
if ((cp = strstr(modestr,"fclk="))) {
bc->cfg.fclk = simple_strtoul(cp+5, NULL, 0);
if (bc->cfg.fclk < 1000000)
--
2.20.1

2022-03-17 05:48:41

by Dan Carpenter

Subject: Re: [PATCH] hamradio: Fix wrong assignment of 'bbc->cfg.loopback'

On Tue, Mar 15, 2022 at 03:48:51PM +0800, Meng Tang wrote:
> In file hamradio/baycom_epp.c, the baycom_setmode interface, there
> is a problem with improper use of strstr.
>
> Suppose that when modestr="noloopback", both conditions which are
> 'strstr(modestr,"noloopback")' and 'strstr(modestr,"loopback")'
> will be true(not NULL), this lead the bc->cfg.loopback variable
> will be first assigned to 0, and then reassigned to 1.
>
> This will cause 'bc->cfg.loopback = 0' will never take effect. That
> obviously violates the logic of the code, so adjust the order of
> their execution to solve the problem.
>
> Signed-off-by: Meng Tang <[email protected]>

Reviewed-by: Dan Carpenter <[email protected]>

This bug predates git. :P Did you find it by testing or reviewing the
code?

regards,
dan carpenter