sRGB by definition can't be greater than 1 or less than 0. If you have an sRGB texture (e.g. for diffuse albedo), it should be converted to linear by the hardware automatically when sampling if you use the right texture format. This produces a linear value in the range [0,1]. Then you can use this linear value for lighting calculations in a shader. When the final HDR pixel value is calculated, which can be in the range [0,infinity], then you can apply tone mapping to bring it back to the [0,1] linear range for display. If your default framebuffer is sRGB, then you can get the hardware to automatically convert the [0,1] linear to [0,1] sRGB.

It's important to understand the point of sRGB. It only exists to fit a wider dynamic range into a limited 8-bit precision, which is why I think you have an HDR image import bug in your other thread. HDR should not have an sRGB curve.

Josh Klint said:
light color and cubemaps should always be stored in linear space.

That's true. I use 16F formats for reflection and ambient diffuse cube maps, as well as for the whole post-processing pipeline and any intermediate results. Light color is expressed in linear lux or W/m^2 and can be in range [0,infinity). The only place I use sRGB is for diffuse albedo texture and the final framebuffer displayed to the user. Everything else is linear, even if only 8 bits (normals, ambient occlusion, roughness, metalness, displacement, etc.).