From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 92FA915C158 for ; Tue, 24 Feb 2026 16:17:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771949869; cv=none; b=qvh2ubAhyq5bFWrA63fZLJIsF52e9TxmymIMn7ViTcDTS+kKUo/qXlVvVt8V0+iPQOvcochPLjsU6tQ74kx3L5h19IEiJ/Nb2ItnCFeMNhpAhsifo1nSLgmuggNtofT2Kkb7GeEi3Se+FpElD5e19/9io9Fm1otOjJ+W9rnyT/Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771949869; c=relaxed/simple; bh=5qYXiIRCciWO54m1S4mmsPBO7kPMbItrGtUKGOVRwoA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DTOHsCcOeWHloiAbSyEztcPc1raaCpXvAF1d9amRb+bBl5d4tckrACGTHB116PCs3E5Eb3EweNg57D4GRkDkONewvL4EpBoXNPjSJOrrXRU/KRbot2mi6StTRyEx04/uONgwt/EcDkTPcH7JhHFRCgqEDZzNF52wHcZETuWXUMo= 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=TTv1KEQd; arc=none smtp.client-ip=209.85.221.49 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="TTv1KEQd" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-43767807cf3so4282792f8f.1 for ; Tue, 24 Feb 2026 08:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771949866; x=1772554666; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IPEhDZiCe09kyOIbSIAFukOzfoSICQjNVF0IQWaOll0=; b=TTv1KEQdIN80Jf6BcTHcuD4jHVYurKNz0ydObP6JjBsHB6eDOH/IjEO1g9xtZROY8S NKjWvRuTUTPrino7tbT2FPcGwqzCDvJfD49OCc/yw0gmb7zKE9dvZTFskdpKHXTUgPiJ 3WKbCUURxtwb6lxjFUCGdmOYF0NLCf5tBvnWYP3MLej0aeC7oYh/VZlDeD11dQNtNC++ QdHNlTjONBfTzoWFkzj0kGntq4IgCaiEouWC8mVQ0lFqZhz6TkwbgMcCUFMPs8xQS1uw FgUZm/YkS9gO8yvbX9zEbXb+nCpZ9jiWhk8K+vIYk6KYajjVryw9BLPGs3B5F3syjdko cJVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771949866; x=1772554666; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IPEhDZiCe09kyOIbSIAFukOzfoSICQjNVF0IQWaOll0=; b=f20n4Y73m9nxlPO77mxFJyddqyUV+Ra3CDc5mkje82Epkjpo0X7ggeWl2npovo20mC IvI7CyweXTFehZZl63cY/sz/LibAIJ7NBp33MD65kCuw8OfzQqQsukWAVf17YARue72j 6wNdCqPRbksFns63ruv6Jux9mvFTKWeL9CBvOmMbYsrW+cSR47lReqjNOrkreWpnthyS WfDMFYe0gtw9rBFqV5Kg71vA0cH4+I/Y4+hAX/TQ+3sAaRickB3xNWixxxRSecVUavw9 VimQcWAr7jpDwuRWvbSewtWehxqipkeJKtKm7aZBTn4fYJldp6D/+THGnBGaRhofYByD p/iw== X-Forwarded-Encrypted: i=1; AJvYcCWIUF6ljeBUCufhsdA36XlpLarHK/HsqcQtXhV/c6qaacT/wNy749jrTVJQEM0/shznwo6rXNs8sHSlZ4c=@vger.kernel.org X-Gm-Message-State: AOJu0YwlnNJCaLzFu7Z3DYklDYGZgLc12NM9mfo8V1kl8EOk8RXwck+m 9uw8zFIZ4wPGjoJ367PuXvzvrmc8t1v6X/UuXdJXVVjLRme9nnM98q0bUysFcw== X-Gm-Gg: ATEYQzycVx7HekQkSVkBzeaNnNCN1egAsuOqeNHEsxTZPz4+uBFCxlTAE5z6+v/giH9 l5ru7haOv8v2GoHnyjIk7azgJk0RieCNTx1bSC7/MIokeXbm2Ss91j3j9g5IkzQXIGtJ8U10mrI W4oIxaJpFv+0dtKj/lV29dNakOGhIkKxwSNHgjkkODG+Et55AfcdfR3roNoIhrpY2G2y6URwQ3O HWYvcG4axg+8ycpWk/NnSOBVyxK+wIwVHx6tagrfac+N6FqJTx9dye0aUFqv3DSTSkQohr3/8Jr PdQI4umRG0CaK4rMqwcFVsOAp5K4DIHMhO20GU/SphW5JP8/ZzL9NJwK0TTFpuDAtNo08AdugEV SsxHyvDrc3bcU8zIgjVOWIZvpdu+W9ndhhB15QHaqJUaUx9lxe7fZyGTikWS83/hg/UbFoKTmwB 7NlvDhx719sUFxBWDYqCRra0LsW6nXrora98gw8ko= X-Received: by 2002:a05:6000:430b:b0:431:808:2d58 with SMTP id ffacd0b85a97d-4396f188c2amr25322503f8f.51.1771949865578; Tue, 24 Feb 2026 08:17:45 -0800 (PST) Received: from LaptopFB.fritz.box ([2001:9e8:7a58:2a00:d0bc:1c7:6190:314f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43970d54a68sm29771117f8f.39.2026.02.24.08.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 08:17:44 -0800 (PST) From: Felix Busch To: phil@philpotter.co.uk Cc: Felix Busch , linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] [PATCH] cdrom: extra upper bound check for logical block address. Date: Tue, 24 Feb 2026 17:16:12 +0100 Message-ID: <20260224161640.16760-1-felixbusch470@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: 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-Transfer-Encoding: 8bit Hi Phillip, Thank you for your feedback. I’ve updated everything based on your suggestions and hope I’ve covered them all. It has been built and run and tested in the following: 1) This has been tested on a real CD-ROM with 700MB capacity, containing 2097151 sectors in my case. Since 2097151 is not divisible by a blocksize of 2048, the if condition is not satisfied. 2) When using a smaller emulated CD-ROM with QEMU with the same blocksize, the if condition is triggered when having a too big logical block addresses. For example, this occurs when minutes, seconds, and frames are set to UINT8_MAX via an ioctl call. According to this SCSI-2 spec, chapter 14 on this web page (date 23.2.2026): https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-introduction.html They are stating: " Logical addressing of CD-ROM information may use any logical block length. When the specified logical block length is an exact divisor or integral multiple of the selected number of bytes per CD-ROM sector, the device shall map (one to one) the bytes transferred from CD-ROM sectors to the bytes of logical blocks. For instance, if 2 048 bytes are transferred from each CD-ROM sector (specified by the CD-ROM density code value), and the logical block length is 512 bytes, then each CD-ROM sector shall map to exactly four logical blocks. This International Standard does not define the mapping of logical block lengths which do not evenly divide or are not exact multiples of the selected number of bytes per CD-ROM sector. " So, I do refer to this SCSI-2 spec. Using this information it's possible to use logical_blocks = cd_nr_sectors / blocksize to get the number of blocks that are be able to read due to this mapping. For now, I decided using this special checking only, due to the given statement in the SCSI-2 spec. If lba > blocksize * (logical_blocks - 1), then it should not be possible to continue reading a full block, because then, as I understand, it would "overflow" the region it can read from the disk. Thanks for your time! Felix To: Phillip Potter Cc: linux-kernel@vger.kernel.org Signed-off-by: Felix Busch --- Changes in v2: - Reviewer feedback. - Link to v1: https://lore.kernel.org/r/20260222-cdrom-additional-lba-check-v1-1-5f5e9f0c0fa4@gmail.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 2, "change-id": "20260222-cdrom-additional-lba-check-2c88d18599d0", "prefixes": [], "history": { "v1": [ "20260222-cdrom-additional-lba-check-v1-1-5f5e9f0c0fa4@gmail.com" ] } } } -- 2.53.0