It should be possible and I believe is somewhat common. What you've drawn is only a ring in terms of how you maintain it, but doesn't actually introduce any cycles in the commit DAG because the branch names (especially 'stable') are moving targets, whereas the commit DAG uses exact parent IDs.
That is, 'feature1' isn't recorded as based on 'stable', it is based on the specific commit that was tip of 'stable' at that point in time. Once you merge 'feature1' into 'dev' and from there to 'stable', this does not retroactively update the base of all feature branches, they retain the same DAG as they had before.
And likewise, merging a branch just integrates the commits from that point in time and doesn't get retroactively updated. So you can safely back-merge 'stable' into 'feature1' during development, and this won't affect the future merge of 'future1' into 'dev'/'stable'. (I see it occasionally done in linux.git but I believe they try to avoid it, because it does generate an ugly-looking DAG.)
Instead of back-merging, you also have the option to manually rebase the feature branch to integrate new work from 'stable'. Though this (like any rewrite) creates new commits on top of the new base, discarding those which are already present in the base. (So rebasing a freshly-merged branch will result in an empty branch.)
It is still impossible to introduce cycles that way because each commit's ID depends on its parent (e.g. if there's A←B, it is outright impossible to rewrite A to get B←A without invalidating the existing pointer that B already has; all you'd get is A←B←A' and not a cycle).