From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D3832370D41 for ; Tue, 31 Mar 2026 05:57:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774936666; cv=none; b=YgRsOxkY6/s8Nv5EUlIjSbOG2srf/MA4tJSZ/R4+s68Mw64yChkfZgGT+xrNYGbtkHTICS9xdCeWaIR6cF6zOWBfB9vuuknti03a6J++HoWbXXeuRfsW0lx+Hul4zDywU8ZoNQFq7nD9sUECa4gQ2IBCx2PvX7o9BP+12QNXqW8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774936666; c=relaxed/simple; bh=MN19Dt2tgg7qpdSYdh0P0F3ljO5qjqclY2MWA50tjCU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YdpNpqvXHf7ETRo2gotJN8/egJl2M8bGSfunuKy06yYytuOp0onxEmu5YwZcXAif64ez7O6Uno8NE2MApKNs1IdDRai7G1/ecMJC4BUXq66YC+Ci3r6/trjZ0JE7jEJmZriAvtre/Y/tPq2sOlS0Vwn548AAM51ZJwN1Fc1nWSo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BPoytBZe; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BPoytBZe" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43cff5dafc3so1389468f8f.1 for ; Mon, 30 Mar 2026 22:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774936663; x=1775541463; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=G58gU/Tx5GYmRFPwnfdaPc4pW0qhkafR56frkg81+YU=; b=BPoytBZeDvpy9gDxEwybDioD8zISoLgFop4FS+NBRVtYbkVotrySA065Tqm0pZj1la 4GzGB7NkEhI6BxRr88a688ADMjuX1ah6jIAt8ci9zmtJ7LfmGtQ+gKrqLBR75khmu+/U Yf30oXF/3O4wAJDUAHNApeATd8QtVHFcVQNKsO7k3HEtz94W1McrJGgxxNafW0ttXUlc LE9bDDZNQzp1rleljInY8pcrwzaRY4tNLqPq6AHdHcxwNgnmvKB0vtA5mUB6opLjPG3G phL3OfHzzdh6DqEla37+iX9MXljh9bdz04D01U4e36kKs5H0KIFWMd4Shp5BUFQlAupR c91g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774936663; x=1775541463; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=G58gU/Tx5GYmRFPwnfdaPc4pW0qhkafR56frkg81+YU=; b=VzkWq5we1gDKtQfy7snkYDbMesNoFoD7TflY9DlNfRLHxM2+ui1jsTfFCVpbjZ9VXX +IX0VDyM1cJ20MxvMn0DynmfjFeQrioBc/tXz9djZl/Y6S82B8mPt7dTuCbTfOVB11F4 srA6kGrIfmfkbB/759HCcvLwJoMh+EZlZRkg5dLj1V/CLlSHoMjCSQcdrni4AedEup94 UBc/SeIDafTnhFxfp1nBHb9P3v5OffME3QVeOSUn7nnF9gAdshXGqNb4zyIMw1T+82rw m8IeFOt+oxQ17CQIEW6BuvsOBFUSxlIZTRQ+Jpetaeswa6sWImO9Fb0sWDYOMw996k9f ql+A== X-Forwarded-Encrypted: i=1; AJvYcCUvShketfw/rFEvA0zfaQ+98vf5XPuJv+Kkw9Zd/9TqortzEQE6PTnsaLHYiiYdBwDVMr2sA7M4DJWtynQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yzma9p8DXh4R81v28xx+E3w93I1/dBD5lXpgdZMMMdhhp8aH2oe yg7BYJIHgsVwOjOaM2DkvFnUOUsKs4Jn/CWK8oRRHqfwUo9tpUNjvfyc X-Gm-Gg: ATEYQzwqI2Y+81UYUidCmJ9bgyfsb4vRj6Qx81R1KqQzb66CVkuyE7aKMsdxFiwu2Xo dwN1x9IQXPuy3kVg42Ph2OA8Mh9OoCXsKcGUS0pLgXHXBjIvzlc4UjgnsNFdc1XSs54APObi1IK 1MyzFLO+gy7EGr0yA/9xjAM5FTXbo3Mp8tyUw1VowDsicEA90s5BE/l/btX6Q4FPeOsMzbGShG2 lbBIxkDXgUaXsvwVdU/HYPtdBgdApQNGhCj7bJc7729iFlqcfFUzsCKzR6AMo7XHTPspIF2xMkb poYVR3h2hxE/PSAhRXe///sOMRS71TT9Ho4kDiPHiUSEUJSHaH2ZQKKpL9/50V99xrt5hoWgcCQ z+swVtuWvZIlT1+p3Y5bT6GrkCjX87cm3xcHIvlTuMr+u91yJFYJcWPHTld6BHvDEmce6vjOT1K NXGo2bfnXZc3YKnzL4BJjnnLJdS5xPUw== X-Received: by 2002:a05:6000:4027:b0:43a:580:f60d with SMTP id ffacd0b85a97d-43b9ea4a5b4mr25852858f8f.35.1774936662981; Mon, 30 Mar 2026 22:57:42 -0700 (PDT) Received: from gmail.com ([2a00:f41:1882:1f28:c460:96ff:fea3:6e21]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43cf90424fcsm19431092f8f.32.2026.03.30.22.57.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 22:57:42 -0700 (PDT) Date: Tue, 31 Mar 2026 07:57:39 +0200 From: "Jose A. Perez de Azpillaga" To: Andy Shevchenko Cc: linux-staging@lists.linux.dev, Hans de Goede , Mauro Carvalho Chehab , Sakari Ailus , Andy Shevchenko , Greg Kroah-Hartman , Alan Cox , azpijr@gmail.com, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/2] media: atomisp: fix potential NULL pointer dereference in configure_isp_from_args() Message-ID: References: <20260328192721.255493-1-azpijr@gmail.com> <20260328192721.255493-2-azpijr@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Mar 30, 2026 at 11:59:24AM +0300, Andy Shevchenko wrote: > On Sat, Mar 28, 2026 at 9:27 PM Jose A. Perez de Azpillaga > wrote: > > > > The function configure_isp_from_args() incorrectly dereferences > > args->delay_frames[0] to configure cropping without checking if the > > pointer is valid. However, as noted in a FIXME comment later in the > > same function, delay_frames can be NULL in certain pipeline > > configurations. > > > > Add defensive checks for both delay_frames and tnr_frames before passing > > them to their respective configuration functions. This ensures that > > optional frames are only processed if they were actually allocated, > > preventing a kernel NULL pointer dereference. > > Have you experienced bugs IRL? > not really, I don't have the hardware, but while reading the code, I found it to be logically inconsistent. imo, the comment is misplaced since delay_frames can be null earlier. > ... > > > /* > > - * FIXME: args->delay_frames can be NULL here > > - * > > - * Somehow, the driver at the Intel Atom Yocto tree doesn't seem to > > - * suffer from the same issue. > > - * > > - * Anyway, the function below should now handle a NULL delay_frames > > - * without crashing, but the pipeline should likely be built without > > - * adding it at the first place (or there are a hidden bug somewhere) > > + * Safely handle pipelines built without delay_frames > > */ > > This comment suggests something different. What the proposed change is > doing is just skipping the invalid data without actual understanding > of the root cause. > you are right here. I should've done a deeper analysis instead of focusing only on that function. looking more closely at how the pipeline is built, I found that these frames are intentionally skipped during allocation to save memory when a specific feature isn't enabled. the configuration path was just ignoring those enable flags and trying to use the frames anyway. instead of a NULL check, maybe I should try gating these calls behind the actual feature flags in the binary info. if this is a better approach, I'll send a v2 with these changes. :) ... regards, jose a. p-a