netdev - Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180106150621.2221a646@alans-desktop>
Date:   Sat, 6 Jan 2018 15:06:21 +0000
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Christian Lamparter <chunkeey@...il.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        peterz@...radead.org, netdev@...r.kernel.org,
        linux-wireless@...r.kernel.org,
        Elena Reshetova <elena.reshetova@...el.com>,
        gregkh@...uxfoundation.org, tglx@...utronix.de,
        torvalds@...ux-foundation.org, Kalle Valo <kvalo@...eaurora.org>,
        alan@...ux.intel.com
Subject: Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via
 speculative execution

> The only way a user can set this in any meaningful way would be via
> a NL80211_CMD_SET_WIPHY netlink message. However, the value will get
> vetted there by cfg80211's parse_txq_params [0]. This is long before

Far more than a couple of hundred instructions ? The problem is that the
processor will speculate that the parameter is valid and continue on that
basis until the speculation resolves or it hits some other limit that
stops it speculating further. That can be quite a distance on a modern
x86 processor, and for all we know could be even more on some of the
other CPUs involved.

> it reaches any of the *_op_conf_tx functions.
> 
> And Furthermore a invalid queue (param->ac) would cause a crash in 
> this line in mac80211 before it even reaches the driver [1]:
> |	sdata->tx_conf[params->ac] = p;
> |                   ^^^^^^^^

Firstly it might not because the address you get as a result could be
valid kernel memory. In fact your attackers wants it to be valid kernel
memory since they are trying to find the value of a piece of that memory.

Secondly the processor is doing this speculatively so it won't fault. It
will eventually decide it went the wrong way and throw all the
speculative work away - leaving footprints. It won't fault unless the
speculative resolves that was the real path the code took.

If it's not a performance critical path then it's better to be safe.

Alan