Hi Greg,
I recently found a bug in the rsvp traffic classifier in the Linux kernel. This classifier is already retired in the upstream but affects stable releases.
The symptom of the bug is that the kernel can be tricked into accessing a wild pointer, thus crash the kernel.
Since it is just a crash and cannot be used for LPE, I do not want to trouble security@kernel.org. And since the classifier is already retired in the upstream, I cannot report there.
Since it affects stable releases, I decided to report it here. If it is not appropriate, I appologize in advance and wonder what will be a good channel to report bugs that only affects stable releases and no equivalent fix exists in the upstream.
[Root Cause] The root cause of the bug is an slab-out-of-bound access, but since the offset to the original pointer is an `unsign int` fully controlled by users, the behaviour is ususally a wild pointer access.
in `rsvp_change`, RSVP_PINFO is passed to the kernel without any checks ~~~ static int rsvp_change(...) { ...... if (tb[TCA_RSVP_PINFO]) { pinfo = nla_data(tb[TCA_RSVP_PINFO]); f->spi = pinfo->spi; f->tunnelhdr = pinfo->tunnelhdr; } ...... if (pinfo) { s->dpi = pinfo->dpi; s->protocol = pinfo->protocol; s->tunnelid = pinfo->tunnelid; } ...... } ~~~
As a result, later when the classifier actually does the classification in `rsvp_classify`: ~~~ TC_INDIRECT_SCOPE int RSVP_CLS(struct sk_buff *skb, const struct tcf_proto *tp, struct tcf_result *res) { ...... *(u32 *)(xprt + s->dpi.offset) ^ s->dpi.key) ...... } ~~~ `xprt + s->dpi.offset` becomes a wild pointer and crashes the kernel.
[Severity] This will cause a local denial-of-service.
[Patch] I don't know enough about this subsystem to suggest a proper patch. But I will suggest to retire rsvp classifier completely just like in the upstream.
[Affected Version] I confirmed that this bug affects v5.10, v6.1, and v6.2.
[Proof-of-Concept] A POC file is attached to this email.
[Splash] A kernel oops splash is attached to this email.
Best, Kyle Zeng
On Thu, Sep 07, 2023 at 05:01:23PM -0700, Kyle Zeng wrote:
Hi Greg,
I recently found a bug in the rsvp traffic classifier in the Linux kernel. This classifier is already retired in the upstream but affects stable releases.
The symptom of the bug is that the kernel can be tricked into accessing a wild pointer, thus crash the kernel.
Since it is just a crash and cannot be used for LPE, I do not want to trouble security@kernel.org. And since the classifier is already retired in the upstream, I cannot report there.
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
thanks,
greg k-h
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Regards, Kyle Zeng
On Mon, Sep 11, 2023 at 07:51:38PM -0700, Kyle Zeng wrote:
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Great, so if we apply this change, all will work properly again? How far back should this be backported to?
thanks,
greg k-h
On Wed, Sep 13, 2023 at 10:12:55AM +0200, Greg KH wrote:
On Mon, Sep 11, 2023 at 07:51:38PM -0700, Kyle Zeng wrote:
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Great, so if we apply this change, all will work properly again? How far back should this be backported to?
thanks,
greg k-h
Great, so if we apply this change, all will work properly again?
Yes, after applying the patch (which is to retire the rsvp classifier), it is no longer possible to trigger the crash. However, you might want to decide whether it is OK to retire the classifier in stable releases.
How far back should this be backported to?
I tested all the stable releases today, namely, v6.1.y, v5.15.y, v5.10.y, v5.4.y, v4.19.y, and v4.14.y. They are all affected by this bug. I think the best approach is to apply the patch to all the stable trees.
Thanks, Kyle Zeng
On Wed, Sep 13, 2023 at 05:04:16PM -0700, Kyle Zeng wrote:
On Wed, Sep 13, 2023 at 10:12:55AM +0200, Greg KH wrote:
On Mon, Sep 11, 2023 at 07:51:38PM -0700, Kyle Zeng wrote:
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Great, so if we apply this change, all will work properly again? How far back should this be backported to?
thanks,
greg k-h
Great, so if we apply this change, all will work properly again?
Yes, after applying the patch (which is to retire the rsvp classifier), it is no longer possible to trigger the crash. However, you might want to decide whether it is OK to retire the classifier in stable releases.
How far back should this be backported to?
I tested all the stable releases today, namely, v6.1.y, v5.15.y, v5.10.y, v5.4.y, v4.19.y, and v4.14.y. They are all affected by this bug. I think the best approach is to apply the patch to all the stable trees.
Great, can you provide backported patches to those trees so that we can queue this up for them?
thanks,
greg k-h
On Sat, Sep 16, 2023 at 01:41:33PM +0200, Greg KH wrote:
On Wed, Sep 13, 2023 at 05:04:16PM -0700, Kyle Zeng wrote:
On Wed, Sep 13, 2023 at 10:12:55AM +0200, Greg KH wrote:
On Mon, Sep 11, 2023 at 07:51:38PM -0700, Kyle Zeng wrote:
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Great, so if we apply this change, all will work properly again? How far back should this be backported to?
thanks,
greg k-h
Great, so if we apply this change, all will work properly again?
Yes, after applying the patch (which is to retire the rsvp classifier), it is no longer possible to trigger the crash. However, you might want to decide whether it is OK to retire the classifier in stable releases.
How far back should this be backported to?
I tested all the stable releases today, namely, v6.1.y, v5.15.y, v5.10.y, v5.4.y, v4.19.y, and v4.14.y. They are all affected by this bug. I think the best approach is to apply the patch to all the stable trees.
Great, can you provide backported patches to those trees so that we can queue this up for them?
thanks,
greg k-h
I backported the patch to all the mentioned affected versions and I used my poc code to make sure that the crash is no longer triggerable after applying the patch.
The patches are sent separately with [PATCH <version>] tags.
Thanks, Kyle Zeng
On Tue, Sep 19, 2023 at 07:27:34PM -0700, Kyle Zeng wrote:
On Sat, Sep 16, 2023 at 01:41:33PM +0200, Greg KH wrote:
On Wed, Sep 13, 2023 at 05:04:16PM -0700, Kyle Zeng wrote:
On Wed, Sep 13, 2023 at 10:12:55AM +0200, Greg KH wrote:
On Mon, Sep 11, 2023 at 07:51:38PM -0700, Kyle Zeng wrote:
On Fri, Sep 08, 2023 at 07:17:12AM +0100, Greg KH wrote:
Great, can you use 'git bisect' to track down the commit that fiexes this so we can add it to the stable trees?
Sorry for the late reply. I think the fix was to completely retire the rsvp classifier and the commit is:
265b4da82dbf5df04bee5a5d46b7474b1aaf326a (net/sched: Retire rsvp classifier)
Great, so if we apply this change, all will work properly again? How far back should this be backported to?
thanks,
greg k-h
Great, so if we apply this change, all will work properly again?
Yes, after applying the patch (which is to retire the rsvp classifier), it is no longer possible to trigger the crash. However, you might want to decide whether it is OK to retire the classifier in stable releases.
How far back should this be backported to?
I tested all the stable releases today, namely, v6.1.y, v5.15.y, v5.10.y, v5.4.y, v4.19.y, and v4.14.y. They are all affected by this bug. I think the best approach is to apply the patch to all the stable trees.
Great, can you provide backported patches to those trees so that we can queue this up for them?
thanks,
greg k-h
I backported the patch to all the mentioned affected versions and I used my poc code to make sure that the crash is no longer triggerable after applying the patch.
The patches are sent separately with [PATCH <version>] tags.
All now queued up, thanks for the backports.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Kyle Zeng