netdev - Re: [PATCH net v2 1/2] mlx5: fix possible ptp queue fifo overflow

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: <85fe01df-e194-2f3c-f20a-99a71051d1d9@meta.com>
Date:   Tue, 24 Jan 2023 16:03:42 +0000
From:   Vadim Fedorenko <vadfed@...a.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Vadim Fedorenko <vfedorenko@...ek.ru>
CC:     Vadim Fedorenko <vadfed@...a.com>, Aya Levin <ayal@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Gal Pressman <gal@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2 1/2] mlx5: fix possible ptp queue fifo overflow

On 24/01/2023 04:19, Jakub Kicinski wrote:
> On Tue, 24 Jan 2023 03:08:35 +0300 Vadim Fedorenko wrote:
>> From: Vadim Fedorenko <vadfed@...a.com>
>>
>> Fifo pointers are not checked for overflow and this could potentially
>> lead to overflow and double free under heavy PTP traffic.
>>
>> Also there were accidental OOO cqe which lead to absolutely broken fifo.
>> Add checks to workaround OOO cqe and add counters to show the amount of
>> such events.
> 
> May be worth adding a mention of the brokenness of the empty() check.
> Comparing free running counters works well unless C promotes the types
> to something wider than the counters themselves. So unsigned or u32
> works, but comparing two u16s or u8s needs a explicit cast.
> 
Yep, sure, will add it to the next version

>> -static void mlx5e_ptp_skb_fifo_ts_cqe_resync(struct mlx5e_ptpsq *ptpsq, u16 skb_cc, u16 skb_id)
>> +static bool mlx5e_ptp_skb_fifo_ts_cqe_resync(struct mlx5e_ptpsq *ptpsq, u16 skb_cc, u16 skb_id)
>>   {
>>   	struct skb_shared_hwtstamps hwts = {};
>>   	struct sk_buff *skb;
>>   
>>   	ptpsq->cq_stats->resync_event++;
>>   
>> -	while (skb_cc != skb_id) {
>> -		skb = mlx5e_skb_fifo_pop(&ptpsq->skb_fifo);
>> +	if (skb_cc > skb_id || PTP_WQE_CTR2IDX(ptpsq->skb_fifo_pc) < skb_id) {
> 
> Are you sure this works for all cases?
> Directly comparing indexes of a ring buffer seems dangerous.
> We'd need to compare like this:
> 
> 	(s16)(skb_cc - skb_id) < 0
>

Here I would like to count (and skip re-syncing) all the packets that 
are not going to be in FIFO. Your suggestion will not work for the 
simplest example. Imagine we have FIFO for 16 elements, and current 
counters are:
  (consumer) skb_cc = 13, (producer) skb_pc = 15, so 3 packets are in.
Then skb_id = 10 arrives out-of-order. It will be counted because of 
(skb_cc > skb_id), but will not be catched by (skb_cc - skb_id) < 0.
To cover all other cases let's continue. Let's think that 2 more packets 
landed in the queue, now we have skb_cc = 13, skb_pc = 1 (because of 
wraparound). skb_id = 11 comes and it's still out of order and will be 
catched by the same check. Then let's assume that skb_id 13,14,15 
arrived and moved our consumer pointer, now we have skb_cc = 0, skb_pc = 
1. If skb_id = 12 arrives, it will be catched by 
PTP_WQE_CTR2IDX(ptpsq->skb_fifo_pc) < skb_id.

So I believe we should be fine here and catch all out-of-order (older 
than skb_cc) skbs.

>> +		ptpsq->cq_stats->ooo_cqe++;
>> +		return false;
>> +	}
> 
>> @@ -128,7 +141,8 @@ static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq,
>>   	ptpsq->cq_stats->cqe++;
>>   
>>   out:
>> -	napi_consume_skb(skb, budget);
>> +	if (skb)
>> +		napi_consume_skb(skb, budget);
> 
> I think napi_consume_skb() takes NULLs.

Yep, will remove this piece.