Re: [PATCH] I2C/ACPI: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

Hi people,

thanks for the additional information here.

> > Sorry for later response due to leave home today. acpi_gsb_i2c_read_bytes()
> > dedicates for GenericSerialBus Read/Write N Bytes protocol(ACPI Spec
> > 5.5.2.4.5.3.8). Bios wants to read N Bytes when uses this protocol and the
> > length specified by Bios should be greater than 1. If the Bios specified 0
> > bytes, the associated function(E,G read battery info) would be totally unusable.
> > I think such Bios can't pass through Windows certification:). From this point, I
> > think the check is not necessary.

The simple question behind this is: Do I trust the caller? When I look
at BIOS (or anything outside the kernel for that matter), I clearly say
no, so...

> > If you still thought this maybe happen, I think it makes more sense to add the
> > check length in the ACPICA. Because ACPICA will allocate a data buffer for I2C
> > ACPI operation region access before call the callback. The buffer length will be
> > result of protocol head length plus data length. If data length is 0 and this
> > means the access will be invalid and ACPICA should ignore it or produce a warning.

... I'd think such a check in ACPICA should be made. However, I can
still ask the question if I trust callers outside my subsystem. This is
more policy. We can demand that users of acpi_i2c_space_handler() should
sanity check their arguments. Any foreseeable chance there will be
another user other than ACPICA? I'd think no?

Regards,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]