Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 15 Jan 2020 23:02:39 +0100
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "istotlan@ingas-xps13.amr.corp.intel.com" 
        <istotlan@ingas-xps13.amr.corp.intel.com>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 0/1] Sequence number out of range fix
Message-ID: <20200115220239.x3jnpn5z6strqwr4@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "istotlan@ingas-xps13.amr.corp.intel.com" <istotlan@ingas-xps13.amr.corp.intel.com>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20200115170830.7479-1-jakub.witowski@silvair.com>
 <4da92cbf6134822629bd2204fb7161c04008780e.camel@intel.com>
 <20200115190904.qcusabsj3ti7sid4@kynes>
 <4C48D122-7887-4A5E-9E3C-0A2FE15D6A1A@intel.com>
 <20200115210414.fvywao5evmbx5725@kynes>
 <456a42fe1d521b9c61bb54bacbddf7b99573df5f.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <456a42fe1d521b9c61bb54bacbddf7b99573df5f.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

On 01/15, Gix, Brian wrote:
> > Now, this raw value is used in send_seg, passed to
> > mesh_crypto_packet_build, which effectively applies a 24bit mask in line
> > 640:
> 
> Yes, we should definitely be sanity checking this, and not sending if
> SeqNum out of range.

Ok, we'll do that then.

> I think if we are repeatedly crashing, and it is causing a runaway
> sequence number increase, that being forbidden to send more packets is
> a natural consequence, and people should fix the code that was causing
> the crash in the first place.

You don't say. But it's not a given that the code is in the daemon
itself. Two words: OOM killer.

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND