The security model of the GPU itself doesn't really allow any level of security within the context - if you can write shader code (e.g. massage the glsl/hlsl into doing what you want, or just upload a binary shader of your own) you already can read anything mapped into that context. I think there's some systems that add stricter validation onto those shaders to disallow things like out-of-bounds reads, and that may have bugs that will cause issues if any security relies on that - e.g. for browsers when sourcing shaders from webgl, or anything where untrusted sources share the same context as possible private info. But that's built on top of the GPU driver's model itself, and provides a restricted model to it's clients. This would just be another thing they disallow.
This "Driver in the GPU" will just be code ran in that context already, so I don't see it as increasing the attack surface. It may be an issue if people start wanting finer grain permissions within a context, however.
But they should be detected and that context killed (or reset in a way that may lose the current job's state) - all other contexts should keep their state. Though task switching is often a lot cruder than on CPUs, so during that timeout other tasks may be blocked - so other renders (including the window system) will be wedged until it's reset. This may mean that a bad actor with access to the GPU can try a denial of service style attack, throwing constant bad tasks at the GPU and causing it to wedge repeatedly, which can certainly be annoying.