Hi all,
I wanted to share a resource I've been using to help me with doing
backports to various stable kernels.
In the Stable Kernel world, when we need to backport a patch, we'd
rather take any relevant dependencies to make the patch work cleanly on
an older kernel, rather than modifying the patch and diverging from
upstream.
This raises an interesting problem: how do we figure out which other
patches might be "interesting" to look at? git-blame is a great tool,
but it takes a while to go through the history of a patch, and given the
volume of patches we need to look at, it just isn't enough.
So here's a tool in the form of a git repo that can help point out these
interesting patches:
https://git.kernel.org/pub/scm/linux/kernel/git/sashal/deps.git/
How does it work, you might ask? It's actually quite simple: Each
directory represents a kernel version which we'll call K, and each file
inside that directory is named after an upstream commit we'll call C,
and it's content are the list of commits one would need to apply on top
of kernel K to "reach" commit C.
For example, let's say we want to apply:
f8788d86ab28 ("Linux 5.6-rc3")
On top of the v5.5 kernel tree. All we need to do is:
$ cat v5.5/f8788d86ab28f61f7b46eb6be375f8a726783636
f8788d86ab28 ("Linux 5.6-rc3")
11a48a5a18c6 ("Linux 5.6-rc2")
bb6d3fb354c5 ("Linux 5.6-rc1")
If you don't feel like cloning the repo (which contains quite a few
files), you can also use kernel.org's web interface in a script that
might look something like this:
#!/bin/bash
curl https://git.kernel.org/pub/scm/linux/kernel/git/sashal/deps.git/plain/$1/$2
And then simply:
$ ./deps.sh v5.5 f8788d86ab28f61f7b46eb6be375f8a726783636
f8788d86ab28 ("Linux 5.6-rc3")
11a48a5a18c6 ("Linux 5.6-rc2")
bb6d3fb354c5 ("Linux 5.6-rc1")
Caveats:
- Each file is limited to 50 entries. I feel that at that point it
stops being useful.
- Each file stops if a merge commit is hit.
- I might have bugs in my scripts and some entries are broken, please
report those if you see them.
--
Thanks,
Sasha
[back to public]
[original thread [PATCH Backport to stable/linux-4.14.y] make 'user_access_begin()' do 'access_ok()']
>
> On Thu, Apr 02, 2020 at 09:00:14AM +0000, Schmid, Carsten wrote:
> > Well, your view, and i completely understand your POV.
> >
> > Mine is (i don't have such a pretty recording of a discussion, so some
> words):
> > - A "CVE" describes a vulnerability found in some product in some version.
> > Nothing else. It's kind of a "vulnerability identifier".
> > - The information collected around the CVE tries to explain (i intentionally
> write "tries")
> > which countermeasures could be taken to mitigate.
> > The quality is sometimes good, sometimes not - that really bothers.
> > - And finally, a "CVE fix" is nothing else than a collection of changes to the
> product to be done.
> > This can be even different for the same vulnerability on different
> products.
> > It's not only a commit id, nor only one CID. Its most times a collection of
> them.
> >
> > I totally agree:
> > "A bug is a bug is a bug" (and not always a feature like some people say ;-) )
> >
> > In Linux kernel context:
> > - The best way to mitigate is to use latest and greatest - or latest LTS.
> Whatever fits.
> > I totally agree.
> >
> > - In case i am a developer who is told by the customer and the chip vendor:
> > - We have a vendor kernel
> > - We follow upstream LTS
> > - We have millions of devices in the field with dedicated setup
> > - Updates need to be tested carefully for our products
> > - We only have a subset of the kernel functions active
> > then things are quite different.
> > - There is a delay in between the LTS going into vendor kernel (10-20
> weeks or so)
> > (They say they need this time for testing)
> > - There is a delay until integration into the product and updates are tested
> > (This time could also be 10+ weeks)
> > - There are vulnerabilities that temporary can be fixed by cherry-picking
> > (until the next LTS "round" from the vendor kernel arrives)
> > - CVE descriptions of NVD and other sources give at least an impression
> > if it makes sense to try a temporary backport
>
> I will be glad to discuss this and point out where something can be
> fixed, if you want to talk about it in public, as remember, you are not
> the only one in this situation.
>
> greg k-h
Of course, thanks.
And as this is something in networking i add the netdev folks also.
There is one CVE report that affects our project, and is not yet fixed in LTS (current 4.14.174).
It is a leak that data is sent unencrypted - and this really is an issue for us:
From https://access.redhat.com/security/cve/cve-2020-1749
A flaw was found in the Linux kernel's implementation of some networking protocols in IPsec, such as VXLAN and GENEVE tunnels over IPv6. When an encrypted tunnel is created between two hosts, the kernel isn't correctly routing tunneled data over the encrypted link; rather sending the data unencrypted. This would allow anyone in between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality.
I have backported 3 fixes from v5.x to 4.14.147 (our current delivery from vendor), see attached patch files.
Mentioned in https://security-tracker.debian.org/tracker/CVE-2020-1749 the patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
is given as a fix, but only this one is hard to port, so i added 2 more.
From my understanding, in 4.14 the vulnerability exists.
(i did not check yet if it's also an issue in other LTS kernels - but i assume at least in 4.19 it is)
I would be glad to hear your opinion on that.
If you find it worth, i would backport to stable/linux-4.14.y (and maybe 4.19.y too, but i think there is a different patch set needed) and send upstream.
Best regards
Carsten
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
In case we have a region 1 ASCE, our shadow/g3 address can have any value.
Unfortunately, (-1UL << 64) is undefined and triggers sometimes,
rejecting valid shadow addresses when trying to walk our shadow table
hierarchy.
The result is that the prefix cannot get mapped and will loop basically
forever trying to map it (-EAGAIN loop).
After all, the broken check is only a sanity check, our table shadowing
code in kvm_s390_shadow_tables() already checks these conditions, injecting
proper translation exceptions. Turn it into a WARN_ON_ONCE().
Fixes: 4be130a08420 ("s390/mm: add shadow gmap support")
Cc: <stable(a)vger.kernel.org> # v4.8+
Reported-by: Janosch Frank <frankja(a)linux.ibm.com>
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
arch/s390/mm/gmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index 2fbece47ef6f..f3dbc5bdde50 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -787,14 +787,18 @@ static void gmap_call_notifier(struct gmap *gmap, unsigned long start,
static inline unsigned long *gmap_table_walk(struct gmap *gmap,
unsigned long gaddr, int level)
{
+ const int asce_type = gmap->asce & _ASCE_TYPE_MASK;
unsigned long *table;
if ((gmap->asce & _ASCE_TYPE_MASK) + 4 < (level * 4))
return NULL;
if (gmap_is_shadow(gmap) && gmap->removed)
return NULL;
- if (gaddr & (-1UL << (31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11)))
+
+ if (WARN_ON_ONCE(asce_type != _ASCE_TYPE_REGION1) &&
+ gaddr & (-1UL << (31 + (asce_type >> 2) * 11)))
return NULL;
+
table = gmap->table;
switch (gmap->asce & _ASCE_TYPE_MASK) {
case _ASCE_TYPE_REGION1:
--
2.25.1
Hi Greg,
Syzbot has been complaining about KASAN splats due to use-after-free
issues in the l2tp code on 4.4 Android kernels (although I reproduced
with latest 4.4 stable on my laptop):
https://syzkaller.appspot.com/bug?id=de316389db0fa0cd7ced6e564601ea8e56625e…
These have been fixed upstream, but for some reason didn't get picked up
for stable. This series applies to 4.4.y and I've sent patches for 4.9
separately.
Thanks,
Will
--->8
Gao Feng (1):
l2tp: Refactor the codes with existing macros instead of literal
number
Guillaume Nault (5):
l2tp: fix race in l2tp_recv_common()
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()
l2tp: fix duplicate session creation
l2tp: ensure sessions are freed after their PPPOL2TP socket
l2tp: fix race between l2tp_session_delete() and
l2tp_tunnel_closeall()
Shmulik Ladkani (1):
net: l2tp: Make l2tp_ip6 namespace aware
phil.turnbull(a)oracle.com (1):
l2tp: Correctly return -EBADF from pppol2tp_getname.
net/l2tp/l2tp_core.c | 149 ++++++++++++++++++++++++++++++++++---------
net/l2tp/l2tp_core.h | 4 ++
net/l2tp/l2tp_eth.c | 10 +--
net/l2tp/l2tp_ip.c | 17 +++--
net/l2tp/l2tp_ip6.c | 28 +++++---
net/l2tp/l2tp_ppp.c | 110 ++++++++++++++++----------------
6 files changed, 211 insertions(+), 107 deletions(-)
--
2.26.0.rc2.310.g2932bb562d-goog
On 4/3/20 1:34 PM, Christian Brauner wrote:
> On Fri, Apr 03, 2020 at 02:11:39PM +0200, Michael Kerrisk (man-pages) wrote:
>> Dmitry, Andrei,
>>
>> Looking at the contents of the /proc/PID/ns/time_for_children
>> symlink shows an anomaly:
>>
>> $ ls -l /proc/self/ns/* |awk '{print $9, $10, $11}'
>> ...
>> /proc/self/ns/pid -> pid:[4026531836]
>> /proc/self/ns/pid_for_children -> pid:[4026531836]
>> /proc/self/ns/time -> time:[4026531834]
>> /proc/self/ns/time_for_children -> time_for_children:[4026531834]
>> /proc/self/ns/user -> user:[4026531837]
>> ...
>>
>> The reference for 'time_for_children' should be a 'time' namespace,
>> just as the reference for 'pid_for_children' is a 'pid' namespace.
>> In other words, I think the above time_for_children link should read:
>>
>> /proc/self/ns/time_for_children -> time:[4026531834]
>>
>> If you agree with this patch, then it should be marked for
>> stable(a)vger.kernel.org.
>>
>> Signed-off-by: Michael Kerrisk <mtk.manpages(a)gmail.com>
>
> Yeah, that just seems like an oversight.
>
> Acked-by: Christian Brauner <christian.brauner(a)ubuntu.com>
Thanks,
Reviewed-by: Dmitry Safonov <dima(a)arista.com>
Fixes: 769071ac9f20 ("ns: Introduce Time Namespace")
+Cc: stable # v5.6
--
Dmitry