linux-kernel - shift/mask issue in drivers/media/dvb/dvb-usb/mxl111sf-demod.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <63c91051-3cad-409f-a1d5-ee8ed89e4de1@gmail.com>
Date: Tue, 15 Oct 2024 00:21:23 +0100
From: "Colin King (gmail)" <colin.i.king@...il.com>
To: Michael Krufky <mkrufky@...uxtv.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "mailing list: linux-media" <linux-media@...r.kernel.org>
Subject: shift/mask issue in drivers/media/dvb/dvb-usb/mxl111sf-demod.c

Hi,

Static analysis has found a shift/mask issue in 
drivers/media/dvb/dvb-usb/mxl111sf-demod.c in function 
mxl1x1sf_demod_get_tps_hierarchy(), as described as follows:

         /* bit<6:4> - 000:Non hierarchy, 001:1, 010:2, 011:4 */
         if (mxl_fail(ret))
                 goto fail;

         switch ((val & V6_TPS_HIERARCHY_INFO_MASK) >> 6) {
         case 0:
                 *hierarchy = HIERARCHY_NONE;
                 break;
         case 1:
                 *hierarchy = HIERARCHY_1;
                 break;
         case 2:
                 *hierarchy = HIERARCHY_2;
                 break;
         case 3:
                 *hierarchy = HIERARCHY_4;
                 break;
         }

There are two issues. First, the comment states the bits of interest are 
bits <6:4> and yet the shift is by 6 bits, I suspect that should be a 4 
bit shift. Secondly, V6_TPS_HIERARCHY_INFO_MASK is defined in 
drivers/media/usb/dvb-usb-v2/mxl111sf-reg.h as:

#define V6_TPS_HIERARCHY_INFO_MASK  0x40

..so only one bit is being masked, I suspect it should be (0x7 << 4) or 
0x70 for the 3 bits <6:3> or maybe just (0x3 << 4) or 0x30 if we're just 
interested in the bottom two bits for the case 0..3.

Anyhow, I don't have the hardware manual or hardware to test specific 
fixes and I'm 100% about making a fix based on the comment w/o the 
hardware to test this on.

Colin