Bug in Post Count Update

[lostcode]

Hello,

We have found what we believe is a bug that might be a boundary value check missing in the directory software to prevent using negative values in an unsigned datatype when decrementing post count.

We can reproduce this bug easily:


Have a user with a zero post count post a link in the directory.

Then, have the (approved) link deleted by a moderator.

The post count of the user will then be 4,294,967,295 which is.....


2^32-1 = 4,294,967,295

Hence, the number of posts must be stored as an unsigned 32 bit integer. If post number was a signed 32 bit integer, it would display as -1.

Not sure why the post count goes from 0 to -1 instead of 1 to 0, might be something to do with how the vB cleanup tasks (updated post counts, etc) are sequenced. We have not dived that deep into the bug. We can easily reproduce it, as mentioned.

See attached screenshot.

[Brian]

Thanks for the information. I'll look into this in a bit, though in the mean time you can always use the 'Update Categories' tool in the vBa Links Maintenance section to correct any issues with the count.

[Our Sponsors]

[lostcode]

Hi Brian,

No, that does not work. We tried it .... you can see for yourself the results:

http://www.unix.com/members/302012004.html

[lostcode]

OBTW: This is almost certainly a vBadvanced bug versus a vBulletin bug.

We tested this by taking another user with a zero posts count and instead of creating and deleting a directory link, we created and deleted a single post in the regular forums. When we did this, no error.

You can see this user here:

http://www.unix.com/members/302032987.html

If we do this with vBadvanced (links), we get the odd -1 error:

2^32-1 = 4,294,967,295 post count for the user.

[Our Sponsors]

[Brian]

Sorry, I read over part of the post too quickly and thought you were referring to the category counts. You can run the following query to correct the members with the inflated post count:
UPDATE user SET posts = 0 WHERE posts = 4294967295;

I tried every combination of things I could think of to reproduce the issue and the only way I could get it to happen was by "soft deleting" a link, and then physically removing the link using the inline moderation tools. I've applied the fix to solve that to the links/moderate.php file in the download package here, so if you will download the files again and update that one on your server, that should prevent the issue from happening again.