linux-kernel - RE: [PATCH 5.10 1/1] mt76: fix mt7615_init_tx

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]

Date:   Mon, 30 Jan 2023 16:13:11 +0000
From:   Жандарович Никита Игоревич <n.zhandarovich@...tech.ru>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Felix Fietkau <nbd@....name>,
        Lorenzo Bianconi <lorenzo.bianconi83@...il.com>,
        Ryder Lee <ryder.lee@...iatek.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Alexey Khoroshilov" <khoroshilov@...ras.ru>,
        "lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>
Subject: RE: [PATCH 5.10 1/1] mt76: fix mt7615_init_tx_queues() return value

> > > What is the "fault"?
> >
> > In 5.10.y "mt7615_init_tx_queues() returns 0 regardless of how final
> > mt7615_init_tx_queue() performs. If mt7615_init_tx_queue() fails (due
> > to memory issues, for instance), parent function will still
> > erroneously return 0."
> 
> And how can memory issues actually be triggered in a real system?  Is this a
> fake problem or something you can validate and verify works properly?
> 
> Don't worry about fake issues for stable backports please.
> 
> thanks,
> 
> greg k-h

mt7615_init_tx_queue() calls devm_kzalloc() (which can throw -ENOMEM) and mt76_queue_alloc() (which can also fail). It's hard for me to gauge how probable these failures can be. But I feel like at the very least it's a logical sanity check. 

@@ -82,7 +82,7 @@ mt7615_init_tx_queues(struct mt7615_dev *dev)
 	
        ret = mt7615_init_tx_queue(dev, MT_TXQ_MCU, MT7615_TXQ_MCU,
                                   MT7615_TX_MCU_RING_SIZE);
       return 0;

There is no special reason  for mt7615_init_tx_queues() to ignore last 'ret'. If last mt7615_init_tx_queue(), so should mt7615_init_tx_queues(). And upstream patch (b671da33d1c5973f90f098ff66a91953691df582) addresses this as well. 
If you feel differently, I will of course back down.

regards,

Nikita