My guess is that that whatever you use to generate mipmap has a bug and doesn't filter mip levels properly - either "leaks" random color from outside of "valid" area in which pixels of previous levels are stored, or forgets to calculate vaules for some pixels. I.e. there is a bug that affects only last levels of mipmap chain.
To verify that this is the cause, read data back from mip levels of a texture you loaded. Using glReadPixels or whatever. If last mip levels contains garbage - it is fault of your texture loading routine. You could also use GL_LINEAR_MIPMAP_NEAREST filter and see if there's a specific mip level with purple pixels.
To bypass the problem, generate image for the first level and use glGenerateMipmaps
(OpenGL 3+), glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
(OpenGL 2+ or OpenGL 1.4+ - I forgot in which version it was added. Deprecated in OpenGL 3+), or gluBuild2DMipMap(ancient OpenGL versions).
Or you could calculate mipmaps yourself. Box filter isn't hard to implement. Gaussian isn't hard either.
If you generate textures using formula (since you said "generate") another possible scenario is that the formula causes computation error on last mip level which causes garbage colors to appear.
Yet another possible scenario is faulty hardware (you won't believe what kind of picture you can get on overheated GPU with broken cooler) or buggy driver. But that should cause artifacts in many applications, not just in your program.