[PATCH v2] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[PATCH v2] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Wei Jie Law]

wacom_wac_pen_serial_enforce() iterates over a field's usages (up to
field->maxusage) but indexes the report bits by j * report_size:

	for (i = 0; i < report->maxfield; i++) {
		for (j = 0; j < report->field[i]->maxusage; j++) {
			...
			value = hid_field_extract(hdev, raw_data + 1,
						  offset + j * size, size);

In hid_add_field() the usage array is sized max(usage_index,
report_count), so field->maxusage can be far larger than report_count
when a descriptor lists more usages than its Report Count.  A field
declaring Usage Minimum 0 / Usage Maximum 0x2ffe with Report Count 1
gives maxusage == 12288 while the field's bit region is only 8 bits
wide.  The extract at j == 12287 then reads bit offset 12287 * 8, i.e.
byte 12287 of raw_data + 1, roughly 12 KB past a 2-byte received
report.  __extract() performs no bounds check.

The value read that way is stored into wacom_wac->serial[0] and can be
emitted to userspace as an MSC_SERIAL event by wacom_wac_pen_report(),
so this is an information disclosure and not just an out-of-bounds
read.  A malicious device only has to claim vendor id 0x056a for
hid_scan_report() to place it in HID_GROUP_WACOM and have this driver
bound to it, and a single crafted input report is enough to trigger the
read.

Clamp the inner loop to the field's actual report region with
min(maxusage, report_count), so usages that have no report data behind
them are no longer extracted.

Verified on v6.12.104, whose wacom_sys.c is identical to mainline here,
with a UHID reproducer and with an emulated USB device (raw-gadget): a
hardware watchpoint on wacom_wac->serial[0] fires with an out-of-bounds
heap byte while a 2-byte report is being processed, and no longer fires
once the loop is clamped.

Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
---
Changes in v2:
 - No code change: the diff is identical to v1.  Adds the Assisted-by
   tags required by Documentation/process/coding-assistants.rst.

The reproducer is available on request.

Compile-tested on bd5f485f3f02, x86_64 defconfig + CONFIG_HID_WACOM=y.

v1: https://lore.kernel.org/linux-input/20260822120926.153849-1-98lawweijie@gmail.com/

 drivers/hid/wacom_sys.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 0eafa483b7f7..1ea8763b68a8 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -113,8 +113,10 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
 
 	/* Queue events which have invalid tool type or serial number */
 	for (i = 0; i < report->maxfield; i++) {
-		for (j = 0; j < report->field[i]->maxusage; j++) {
-			struct hid_field *field = report->field[i];
+		struct hid_field *field = report->field[i];
+		unsigned int count = min(field->maxusage, field->report_count);
+
+		for (j = 0; j < count; j++) {
 			struct hid_usage *usage = &field->usage[j];
 			unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
 			unsigned int offset;
-- 
2.43.0

Re: [PATCH v2] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Jason Gerecke]

On Tue, Aug 25, 2026 at 3:31 AM Wei Jie Law <98lawweijie@gmail.com> wrote:
>
> wacom_wac_pen_serial_enforce() iterates over a field's usages (up to
> field->maxusage) but indexes the report bits by j * report_size:
>
>         for (i = 0; i < report->maxfield; i++) {
>                 for (j = 0; j < report->field[i]->maxusage; j++) {
>                         ...
>                         value = hid_field_extract(hdev, raw_data + 1,
>                                                   offset + j * size, size);
>
> In hid_add_field() the usage array is sized max(usage_index,
> report_count), so field->maxusage can be far larger than report_count
> when a descriptor lists more usages than its Report Count.  A field

The wording above confused me greatly until I realized that the
problem is **not** with the field->usage array. That particular array
is allocated with the size described, which is exactly equal to
field->maxusage. **Instead**, the problem is that a buggy report
descriptor can declare many more usages (and thus a greater value of
field->maxusage) than the Report Count actually provides space in the
report for. In such an instance, we would obviously overstep
arbitrarily far past the end of the item.

I would appreciate an update to this patch with less confusing wording.

> declaring Usage Minimum 0 / Usage Maximum 0x2ffe with Report Count 1
> gives maxusage == 12288 while the field's bit region is only 8 bits
> wide.  The extract at j == 12287 then reads bit offset 12287 * 8, i.e.
> byte 12287 of raw_data + 1, roughly 12 KB past a 2-byte received
> report.  __extract() performs no bounds check.
>
> The value read that way is stored into wacom_wac->serial[0] and can be
> emitted to userspace as an MSC_SERIAL event by wacom_wac_pen_report(),
> so this is an information disclosure and not just an out-of-bounds
> read.  A malicious device only has to claim vendor id 0x056a for
> hid_scan_report() to place it in HID_GROUP_WACOM and have this driver
> bound to it, and a single crafted input report is enough to trigger the
> read.
>
> Clamp the inner loop to the field's actual report region with
> min(maxusage, report_count), so usages that have no report data behind
> them are no longer extracted.
>

I don't believe there is any situation where maxusage could be less
than report_count since it is initialized as max(usage_index,
report_count). We would also *want* to read fields beyond the
last-declared usage, since such fields are actually supported by HID
(see both the comment in the usages loop of hid_add_field() as well as
the first remark under section 6.2.2.8 "Local Items" of version 1.11
of the HID spec --- such fields just reuse the last-declared usage).

Given the above, I propose simply making the loop condition " j <
field->report_count". Thoughts?

Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....

> Verified on v6.12.104, whose wacom_sys.c is identical to mainline here,
> with a UHID reproducer and with an emulated USB device (raw-gadget): a
> hardware watchpoint on wacom_wac->serial[0] fires with an out-of-bounds
> heap byte while a 2-byte report is being processed, and no longer fires
> once the loop is clamped.
>
> Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5
> Assisted-by: GLM:glm-5.3
> Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
> ---
> Changes in v2:
>  - No code change: the diff is identical to v1.  Adds the Assisted-by
>    tags required by Documentation/process/coding-assistants.rst.
>
> The reproducer is available on request.
>
> Compile-tested on bd5f485f3f02, x86_64 defconfig + CONFIG_HID_WACOM=y.
>
> v1: https://lore.kernel.org/linux-input/20260822120926.153849-1-98lawweijie@gmail.com/
>
>  drivers/hid/wacom_sys.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 0eafa483b7f7..1ea8763b68a8 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -113,8 +113,10 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
>
>         /* Queue events which have invalid tool type or serial number */
>         for (i = 0; i < report->maxfield; i++) {
> -               for (j = 0; j < report->field[i]->maxusage; j++) {
> -                       struct hid_field *field = report->field[i];
> +               struct hid_field *field = report->field[i];
> +               unsigned int count = min(field->maxusage, field->report_count);
> +
> +               for (j = 0; j < count; j++) {
>                         struct hid_usage *usage = &field->usage[j];
>                         unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
>                         unsigned int offset;
> --
> 2.43.0
>
>

[PATCH v3] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Wei Jie LAW]

From: Wei Jie Law <98lawweijie@gmail.com>

wacom_wac_pen_serial_enforce() iterates over a field's usages (up to
field->maxusage) but indexes the report bits by j * report_size, the
position of value slot j -- and only the field->report_count value
slots reserved by the Report Count exist in the report:

	for (i = 0; i < report->maxfield; i++) {
		for (j = 0; j < report->field[i]->maxusage; j++) {
			...
			value = hid_field_extract(hdev, raw_data + 1,
						  offset + j * size, size);

hid_add_field() sizes the usage array with max(usage_index,
report_count), so a report descriptor can declare far more usages
than its Report Count reserves room for in the report.  One listing
12288 usages against Report Count 1 has the loop extract the usage
at index 12287 from bit offset 98296 -- about 12 KB past a 2-byte
received report.  The value is stored in wacom_wac->serial[0] and
can reach userspace as an MSC_SERIAL event, making this an
information disclosure.

Clamp the loop to field->report_count, the number of value slots the
report holds. Value slots past the last declared usage are still
scanned; they reuse that usage (HID 1.11, 6.2.2.8).

Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
such a descriptor trips KASAN before the patch and not after it.

Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
Suggested-by: Jason Gerecke <killertofu@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
---
Changes in v3, per Jason Gerecke's review:

 - reworded the explanation: the usage array is sized for maxusage;
   the descriptor just declares more usages than its Report Count
   reserves room for in the report, and the loop trusted maxusage
   over report_count

 - bound inner loop to field->report_count

The reproducer is available on request.

Compile-tested on 6ba2c27cb9aa (x86_64, wacom_sys.o); the runtime
verification used the identical wacom_sys.c built as a module for
v6.12.105.

v2: https://lore.kernel.org/linux-input/20260825103104.12090-1-98lawweijie@gmail.com/
v1: https://lore.kernel.org/linux-input/20260822120926.153849-1-98lawweijie@gmail.com/

 drivers/hid/wacom_sys.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 0eafa483b7f7..40770affdbde 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -113,8 +113,9 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
 
 	/* Queue events which have invalid tool type or serial number */
 	for (i = 0; i < report->maxfield; i++) {
-		for (j = 0; j < report->field[i]->maxusage; j++) {
-			struct hid_field *field = report->field[i];
+		struct hid_field *field = report->field[i];
+
+		for (j = 0; j < field->report_count; j++) {
 			struct hid_usage *usage = &field->usage[j];
 			unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
 			unsigned int offset;
-- 
2.43.0

Re: [PATCH v3] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Jason Gerecke]

On Thu, Aug 27, 2026 at 8:33 PM Wei Jie LAW <98lawweijie@gmail.com> wrote:
>
> From: Wei Jie Law <98lawweijie@gmail.com>
>
> wacom_wac_pen_serial_enforce() iterates over a field's usages (up to
> field->maxusage) but indexes the report bits by j * report_size, the
> position of value slot j -- and only the field->report_count value
> slots reserved by the Report Count exist in the report:
>

Thanks for the v3!

I'm still finding the above paragraph kinda hard to understand. What
do you think of something like the following instead?

* * * *

The 'wacom_wac_pen_serial_enforce' function may calculate and pass an
invalid offset to 'hid_field_extract', resulting in memory reads at
incorrect addresses--possibly beyond the end of the report. If a field
in the HID descriptor lists more usages than its Report Count actually
reserves space for, the function's inner 'j' will walk past the end of
the field:

* * * *

Other than the above language issue:
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com

Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....

>         for (i = 0; i < report->maxfield; i++) {
>                 for (j = 0; j < report->field[i]->maxusage; j++) {
>                         ...
>                         value = hid_field_extract(hdev, raw_data + 1,
>                                                   offset + j * size, size);
>
> hid_add_field() sizes the usage array with max(usage_index,
> report_count), so a report descriptor can declare far more usages
> than its Report Count reserves room for in the report.  One listing
> 12288 usages against Report Count 1 has the loop extract the usage
> at index 12287 from bit offset 98296 -- about 12 KB past a 2-byte
> received report.  The value is stored in wacom_wac->serial[0] and
> can reach userspace as an MSC_SERIAL event, making this an
> information disclosure.
>
> Clamp the loop to field->report_count, the number of value slots the
> report holds. Value slots past the last declared usage are still
> scanned; they reuse that usage (HID 1.11, 6.2.2.8).
>
> Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
> such a descriptor trips KASAN before the patch and not after it.
>
> Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
> Suggested-by: Jason Gerecke <killertofu@gmail.com>
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5
> Assisted-by: GLM:glm-5.3
> Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
> ---
> Changes in v3, per Jason Gerecke's review:
>
>  - reworded the explanation: the usage array is sized for maxusage;
>    the descriptor just declares more usages than its Report Count
>    reserves room for in the report, and the loop trusted maxusage
>    over report_count
>
>  - bound inner loop to field->report_count
>
> The reproducer is available on request.
>
> Compile-tested on 6ba2c27cb9aa (x86_64, wacom_sys.o); the runtime
> verification used the identical wacom_sys.c built as a module for
> v6.12.105.
>
> v2: https://lore.kernel.org/linux-input/20260825103104.12090-1-98lawweijie@gmail.com/
> v1: https://lore.kernel.org/linux-input/20260822120926.153849-1-98lawweijie@gmail.com/
>
>  drivers/hid/wacom_sys.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 0eafa483b7f7..40770affdbde 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -113,8 +113,9 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
>
>         /* Queue events which have invalid tool type or serial number */
>         for (i = 0; i < report->maxfield; i++) {
> -               for (j = 0; j < report->field[i]->maxusage; j++) {
> -                       struct hid_field *field = report->field[i];
> +               struct hid_field *field = report->field[i];
> +
> +               for (j = 0; j < field->report_count; j++) {
>                         struct hid_usage *usage = &field->usage[j];
>                         unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
>                         unsigned int offset;
> --
> 2.43.0
>

Re: [PATCH v3] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Wei Jie LAW]

On Thu, Sep 3, 2026 at 3:36 PM Jason Gerecke <killertofu@gmail.com> wrote:
>
> I'm still finding the above paragraph kinda hard to understand. What
> do you think of something like the following instead?

Your version is definitely easier to understand. I'm good with it!

> Other than the above language issue:
> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com

Thanks. Should I submit a v4 patch with your "Reviewed-by" and the
updated language, or is leaving it as-is (here) just fine?

Regards,
Wei Jie

Re: [PATCH v3] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Jason Gerecke]

On Thu, Sep 3, 2026 at 7:02 PM Wei Jie LAW <98lawweijie@gmail.com> wrote:
>
>
> On Thu, Sep 3, 2026 at 3:36 PM Jason Gerecke <killertofu@gmail.com> wrote:
> >
> > I'm still finding the above paragraph kinda hard to understand. What
> > do you think of something like the following instead?
>
> Your version is definitely easier to understand. I'm good with it!
>
> > Other than the above language issue:
> > Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com
>
> Thanks. Should I submit a v4 patch with your "Reviewed-by" and the
> updated language, or is leaving it as-is (here) just fine?
>
> Regards,
> Wei Jie

I suspect Benjamin would prefer a v4 with my Reviewed-by attached so
that he doesn't have to make the edits himself.

Thanks for your work on this!

Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....

[PATCH v4] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Wei Jie LAW]

The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
invalid offset to hid_field_extract(), resulting in memory reads at
incorrect addresses -- possibly beyond the end of the report.  If a
field in the HID descriptor lists more usages than its Report Count
actually reserves space for, the function's inner 'j' will walk past
the end of the field:

	for (i = 0; i < report->maxfield; i++) {
		for (j = 0; j < report->field[i]->maxusage; j++) {
			...
			value = hid_field_extract(hdev, raw_data + 1,
						  offset + j * size, size);

A descriptor listing 12288 usages against Report Count 1 has the loop
extract the usage at index 12287 from bit offset 98296 -- about 12 KB
past a 2-byte received report.  The value is stored in
wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event,
making this an information disclosure.

Clamp the loop to field->report_count, the number of value slots the
report holds.  Value slots past the last declared usage are still
scanned; they reuse that usage (HID 1.11, 6.2.2.8).

Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
such a descriptor trips KASAN before the patch and not after it.

Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
Suggested-by: Jason Gerecke <killertofu@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
---

Changes in v4, per Jason Gerecke's review of v3:

 - reworded the opening paragraph using Jason's suggested text; 

 - picked up Jason's Reviewed-by

 - no functional change: the diff is byte-for-byte the v3 diff

Compile-tested on 6ba2c27cb9aa (x86_64, wacom_sys.o); the runtime
verification used the identical wacom_sys.c built as a module for
v6.12.105.

v3: https://lore.kernel.org/linux-input/20260828033323.82958-1-98lawweijie@gmail.com/
v2: https://lore.kernel.org/linux-input/20260825103104.12090-1-98lawweijie@gmail.com/
v1: https://lore.kernel.org/linux-input/20260822120926.153849-1-98lawweijie@gmail.com/

 drivers/hid/wacom_sys.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 0eafa483b7f7..40770affdbde 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -113,8 +113,9 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
 
 	/* Queue events which have invalid tool type or serial number */
 	for (i = 0; i < report->maxfield; i++) {
-		for (j = 0; j < report->field[i]->maxusage; j++) {
-			struct hid_field *field = report->field[i];
+		struct hid_field *field = report->field[i];
+
+		for (j = 0; j < field->report_count; j++) {
 			struct hid_usage *usage = &field->usage[j];
 			unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
 			unsigned int offset;
-- 
2.43.0

Re: [PATCH v4] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Jiri Kosina]

On Wed, 9 Sep 2026, Wei Jie LAW wrote:

> The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
> invalid offset to hid_field_extract(), resulting in memory reads at
> incorrect addresses -- possibly beyond the end of the report.  If a
> field in the HID descriptor lists more usages than its Report Count
> actually reserves space for, the function's inner 'j' will walk past
> the end of the field:
> 
> 	for (i = 0; i < report->maxfield; i++) {
> 		for (j = 0; j < report->field[i]->maxusage; j++) {
> 			...
> 			value = hid_field_extract(hdev, raw_data + 1,
> 						  offset + j * size, size);
> 
> A descriptor listing 12288 usages against Report Count 1 has the loop
> extract the usage at index 12287 from bit offset 98296 -- about 12 KB
> past a 2-byte received report.  The value is stored in
> wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event,
> making this an information disclosure.
> 
> Clamp the loop to field->report_count, the number of value slots the
> report holds.  Value slots past the last declared usage are still
> scanned; they reuse that usage (HID 1.11, 6.2.2.8).
> 
> Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
> such a descriptor trips KASAN before the patch and not after it.
> 
> Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
> Suggested-by: Jason Gerecke <killertofu@gmail.com>
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5
> Assisted-by: GLM:glm-5.3
> Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

[Wei Jie Law]

On Thu, Aug 27, 2026 at 12:02 PM Jason Gerecke <killertofu@gmail.com> wrote:
> I would appreciate an update to this patch with less confusing wording.

Reworded in v3:
https://lore.kernel.org/all/20260828033323.82958-1-98lawweijie@gmail.com/

> I don't believe there is any situation where maxusage could be less
> than report_count since it is initialized as max(usage_index,
> report_count).

You are right. Thanks for the correction.

> We would also *want* to read fields beyond the last-declared usage

Agreed; the submitted v3 keeps that, and the changelog 
notes the 6.2.2.8 reuse rule.

> Given the above, I propose simply making the loop condition " j <
> field->report_count". Thoughts?

That is v3, with Suggested-by: you.  Retested on v6.12.105 with a
kprobe on hid_field_extract(): with your condition the 12288-usage /
Report Count 1 descriptor extracts nothing in the driver loop (the one
remaining call is the core's own in-bounds fetch) and trips no KASAN;
stock extracts at bit offset 98296 and does.

As a side note, I am also looking into a separate but related read in 
the same function based on Sashiko's review. I do not want to hold 
up this patch over it or speculate before I have it pinned down. 
If it turns out to be a real bug I will send it as its own patch.

Also my bad, I realised I had not replied to this thread addressing 
some things you have said, after submitting the v3 patch.

Wei Jie