Arend van Spriel <arend.vanspr...@broadcom.com> writes: > On 9/12/2017 7:48 AM, Kalle Valo wrote: >> Arend van Spriel <arend.vanspr...@broadcom.com> writes: >> >>> On 09-09-17 21:30, Kevin Cernekee wrote: >>>> In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before >>>> the length of rxframe is validated. This could lead to uninitialized >>>> data being accessed (but not printed). Since we already have a >>>> perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec, >>>> and ch.chspec is not modified by decchspec(), avoid the extra >>>> assignment and use ch.chspec in the debug print. >>>> >>>> Suggested-by: Mattias Nissler <mniss...@chromium.org> >>>> Signed-off-by: Kevin Cernekee <cerne...@chromium.org> >>>> Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> >>>> --- >>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +-- >>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>> >>>> >>>> V1->V2: Clarify changelog re: whether the uninitialized data is printed. >>> >>> This patch and the others in this series look fine to me. >> >> Should these go to v4.14? > > I have no strong opinion. These are certainly improvements, but it > does not seem an -rc fix to me. Within this series I would say patch > 3/3 adds an additional sanity check in the event processing against an > attack so you may consider adding just that one to v4.14
Ok, I'll queue patch 3 to v4.14. > and tag it for stable, ie.: > > Cc: sta...@vger.kernel.org # v3.8.x But why v3.8.x? I admit that I haven't fully figured out the stable tags yet, but doesn't that mean that it will be only applied to v3.8.x and nothing else? I was expecting it to be: Cc: sta...@vger.kernel.org # v3.8+ -- Kalle Valo
