- Linux-stable-mirror - lists.linaro.org

[PATCH v2] crypto: caam: Drop leading zero from input buffer

by Fabio Estevam

From: Fabio Estevam <fabio.estevam(a)nxp.com> imx6ul and imx7 report the following error: caam_jr 2142000.jr1: 40000789: DECO: desc idx 7: Protocol Size Error - A protocol has seen an error in size. When running RSA, pdb size N < (size of F) when no formatting is used; or pdb size N < (F + 11) when formatting is used. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at crypto/asymmetric_keys/public_key.c:148 public_key_verify_signature+0x27c/0x2b0 This error happens because the signature contains 257 bytes, including a leading zero as the first element. Fix the problem by stripping off the leading zero from input data before feeding it to the CAAM accelerator. Fixes: 8c419778ab57e497b5 ("crypto: caam - add support for RSA algorithm") Cc: <stable(a)vger.kernel.org> Reported-by: Martin Townsend <mtownsend1973(a)gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> --- Changes since v1: - Use a temp pointer - Assign len to req->src_len , so that more than one leading zero can be taken into account drivers/crypto/caam/caampkc.c | 45 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 37 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c index 7a897209..5f3e627 100644 --- a/drivers/crypto/caam/caampkc.c +++ b/drivers/crypto/caam/caampkc.c @@ -166,6 +166,14 @@ static void rsa_priv_f3_done(struct device *dev, u32 *desc, u32 err, akcipher_request_complete(req, err); } +static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes) +{ + while (!**ptr && *nbytes) { + (*ptr)++; + (*nbytes)--; + } +} + static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req, size_t desclen) { @@ -178,7 +186,36 @@ static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req, int sgc; int sec4_sg_index, sec4_sg_len = 0, sec4_sg_bytes; int src_nents, dst_nents; + const u8 *temp; + void *buffer; + size_t len; + + buffer = kzalloc(req->src_len, GFP_ATOMIC); + if (!buffer) + return ERR_PTR(-ENOMEM); + + sg_copy_to_buffer(req->src, sg_nents(req->src), + buffer, req->src_len); + temp = (u8 *)buffer; + len = req->src_len; + /* + * Check if the buffer contains leading zeros and if + * it does, drop the leading zeros + */ + if (temp[0] == 0) { + caam_rsa_drop_leading_zeros(&temp, &len); + if (!temp) { + kfree(buffer); + return ERR_PTR(-ENOMEM); + } + + req->src_len = len; + sg_copy_from_buffer(req->src, sg_nents(req->src), + (void *)temp, req->src_len); + } + + kfree(buffer); src_nents = sg_nents_for_len(req->src, req->src_len); dst_nents = sg_nents_for_len(req->dst, req->dst_len); @@ -683,14 +720,6 @@ static void caam_rsa_free_key(struct caam_rsa_key *key) memset(key, 0, sizeof(*key)); } -static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes) -{ - while (!**ptr && *nbytes) { - (*ptr)++; - (*nbytes)--; - } -} - /** * caam_read_rsa_crt - Used for reading dP, dQ, qInv CRT members. * dP, dQ and qInv could decode to less than corresponding p, q length, as the -- 2.7.4

7 years, 8 months

2
2
0 0

[PATCH] block: do not use interruptible wait anywhere

by Alan Jenkins

When blk_queue_enter() waits for a queue to unfreeze, or unset the PREEMPT_ONLY flag, do not allow it to be interrupted by a signal. The PREEMPT_ONLY flag was introduced later in commit 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably"). Note the SCSI device is resumed asynchronously, i.e. after un-freezing userspace tasks. So that commit exposed the bug as a regression in v4.15. A mysterious SIGBUS (or -EIO) sometimes happened during the time the device was being resumed. Most frequently, there was no kernel log message, and we saw Xorg or Xwayland killed by SIGBUS.[1] [1] E.g. https://bugzilla.redhat.com/show_bug.cgi?id=1553979 Without this fix, I get an IO error in this test: # dd if=/dev/sda of=/dev/null iflag=direct & \ while killall -SIGUSR1 dd; do sleep 0.1; done & \ echo mem > /sys/power/state ; \ sleep 5; killall dd # stop after 5 seconds The interruptible wait was added to blk_queue_enter in commit 3ef28e83ab15 ("block: generic request_queue reference counting"). Before then, the interruptible wait was only in blk-mq, but I don't think it could ever have been correct. Cc: stable(a)vger.kernel.org Signed-off-by: Alan Jenkins <alan.christopher.jenkins(a)gmail.com> --- block/blk-core.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index abcb8684ba67..5a6d20069364 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -915,7 +915,6 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) while (true) { bool success = false; - int ret; rcu_read_lock(); if (percpu_ref_tryget_live(&q->q_usage_counter)) { @@ -947,14 +946,12 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) */ smp_rmb(); - ret = wait_event_interruptible(q->mq_freeze_wq, + wait_event(q->mq_freeze_wq, (atomic_read(&q->mq_freeze_depth) == 0 && (preempt || !blk_queue_preempt_only(q))) || blk_queue_dying(q)); if (blk_queue_dying(q)) return -ENODEV; - if (ret) - return ret; } } -- 2.14.3

7 years, 8 months

4
7
0 0

[PATCH] crypto: caam: Drop leading zero from input buffer

by Fabio Estevam

From: Fabio Estevam <fabio.estevam(a)nxp.com> imx6ul and imx7 report the following error: caam_jr 2142000.jr1: 40000789: DECO: desc idx 7: Protocol Size Error - A protocol has seen an error in size. When running RSA, pdb size N < (size of F) when no formatting is used; or pdb size N < (F + 11) when formatting is used. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at crypto/asymmetric_keys/public_key.c:148 public_key_verify_signature+0x27c/0x2b0 This error happens because the signature contains 257 bytes, including a leading zero as the first element. Fix the problem by striping off the leading zero from input data before feeding it to the CAAM accelerator. Fixes: 8c419778ab57e497b5 ("crypto: caam - add support for RSA algorithm") Cc: <stable(a)vger.kernel.org> Reported-by: Martin Townsend <mtownsend1973(a)gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> --- drivers/crypto/caam/caampkc.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c index 7a897209..d2ad547 100644 --- a/drivers/crypto/caam/caampkc.c +++ b/drivers/crypto/caam/caampkc.c @@ -166,6 +166,14 @@ static void rsa_priv_f3_done(struct device *dev, u32 *desc, u32 err, akcipher_request_complete(req, err); } +static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes) +{ + while (!**ptr && *nbytes) { + (*ptr)++; + (*nbytes)--; + } +} + static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req, size_t desclen) { @@ -178,7 +186,34 @@ static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req, int sgc; int sec4_sg_index, sec4_sg_len = 0, sec4_sg_bytes; int src_nents, dst_nents; + const u8 *buffer; + size_t len; + + buffer = kzalloc(req->src_len, GFP_ATOMIC); + if (!buffer) + return ERR_PTR(-ENOMEM); + + sg_copy_to_buffer(req->src, sg_nents(req->src), + (void *)buffer, req->src_len); + len = req->src_len; + /* + * Check if the buffer contains leading zero and if + * it does, drop the leading zero + */ + if (buffer[0] == 0) { + caam_rsa_drop_leading_zeros(&buffer, &len); + if (!buffer) { + kfree(buffer); + return ERR_PTR(-ENOMEM); + } + + req->src_len -= 1; + sg_copy_from_buffer(req->src, sg_nents(req->src), + (void *)buffer, req->src_len); + } + + kfree(buffer); src_nents = sg_nents_for_len(req->src, req->src_len); dst_nents = sg_nents_for_len(req->dst, req->dst_len); @@ -683,14 +718,6 @@ static void caam_rsa_free_key(struct caam_rsa_key *key) memset(key, 0, sizeof(*key)); } -static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes) -{ - while (!**ptr && *nbytes) { - (*ptr)++; - (*nbytes)--; - } -} - /** * caam_read_rsa_crt - Used for reading dP, dQ, qInv CRT members. * dP, dQ and qInv could decode to less than corresponding p, q length, as the -- 2.7.4

7 years, 8 months

2
2
0 0

[PATCH stable v4.15 3/3] media: staging: lirc_zilog: incorrect reference counting

by Sean Young

Whenever poll is called, the reference count is increased but never decreased. This means that on rmmod, the lirc_thread is not stopped, and will trample over freed memory. Zilog/Hauppauge IR driver unloaded BUG: unable to handle kernel paging request at ffffffffc17ba640 Oops: 0010 [#1] SMP CPU: 1 PID: 667 Comm: zilog-rx-i2c-1 Tainted: P C OE 4.13.16-302.fc27.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F6 08/06/2009 task: ffff964eb452ca00 task.stack: ffffb254414dc000 RIP: 0010:0xffffffffc17ba640 RSP: 0018:ffffb254414dfe78 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff964ec1b35890 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffffb254414dff00 R08: 000000000000036e R09: ffff964ecfc8dfd0 R10: ffffb254414dfe78 R11: 00000000000f4240 R12: ffff964ec2bf28a0 R13: ffff964ec1b358a8 R14: ffff964ec1b358d0 R15: ffff964ec1b35800 FS: 0000000000000000(0000) GS:ffff964ecfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc17ba640 CR3: 000000023058c000 CR4: 00000000000006e0 Call Trace: kthread+0x125/0x140 ? kthread_park+0x60/0x60 ? do_syscall_64+0x67/0x140 ret_from_fork+0x25/0x30 Code: Bad RIP value. RIP: 0xffffffffc17ba640 RSP: ffffb254414dfe78 CR2: ffffffffc17ba640 Note that zilog-rx-i2c-1 should have exited by now, but hasn't due to the missing put in poll(). This code has been replaced completely in kernel v4.16 by a new driver, see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and commit f95367a7b758 ("media: staging: remove lirc_zilog driver"). Cc: stable(a)vger.kernel.org # v4.15- (all up to and including v4.15) Reported-by: Warren Sturm <warren.sturm(a)gmail.com> Tested-by: Warren Sturm <warren.sturm(a)gmail.com> Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/staging/media/lirc/lirc_zilog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c index e8d6c1abc6d8..022720210f70 100644 --- a/drivers/staging/media/lirc/lirc_zilog.c +++ b/drivers/staging/media/lirc/lirc_zilog.c @@ -1227,6 +1227,7 @@ static unsigned int poll(struct file *filep, poll_table *wait) dev_dbg(ir->dev, "%s result = %s\n", __func__, ret ? "POLLIN|POLLRDNORM" : "none"); + put_ir_rx(rx, false); return ret; } -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH stable v4.15 2/3] Revert "media: lirc_zilog: driver only sends LIRCCODE"

by Sean Young

The lirc config documented here https://www.blushingpenguin.com/mark/blog/?p=24 uses raw_codes for sending IR. Each key only has one pulse, which in fact is an index into the haup-ir-blaster.bin file. Changing the driver to LIRCCODE (although more accurate) breaks this configuration. This code has been replaced completely in kernel v4.16 by a new driver, see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and commit f95367a7b758 ("media: staging: remove lirc_zilog driver"). This reverts commit 89d8a2cc51d1f29ea24a0b44dde13253141190a0. Fixes: 615cd3fe6ccc ("[media] media: lirc_dev: make better use of file->private_data") Cc: stable(a)vger.kernel.org # v4.14-v4.15 Reported-by: Warren Sturm <warren.sturm(a)gmail.com> Tested-by: Warren Sturm <warren.sturm(a)gmail.com> Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/staging/media/lirc/lirc_zilog.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c index bf6869e48a0f..e8d6c1abc6d8 100644 --- a/drivers/staging/media/lirc/lirc_zilog.c +++ b/drivers/staging/media/lirc/lirc_zilog.c @@ -287,7 +287,7 @@ static void release_ir_tx(struct kref *ref) struct IR_tx *tx = container_of(ref, struct IR_tx, ref); struct IR *ir = tx->ir; - ir->l->features &= ~LIRC_CAN_SEND_LIRCCODE; + ir->l->features &= ~LIRC_CAN_SEND_PULSE; /* Don't put_ir_device(tx->ir) here, so our lock doesn't get freed */ ir->tx = NULL; kfree(tx); @@ -1266,14 +1266,14 @@ static long ioctl(struct file *filep, unsigned int cmd, unsigned long arg) if (!(features & LIRC_CAN_SEND_MASK)) return -ENOTTY; - result = put_user(LIRC_MODE_LIRCCODE, uptr); + result = put_user(LIRC_MODE_PULSE, uptr); break; case LIRC_SET_SEND_MODE: if (!(features & LIRC_CAN_SEND_MASK)) return -ENOTTY; result = get_user(mode, uptr); - if (!result && mode != LIRC_MODE_LIRCCODE) + if (!result && mode != LIRC_MODE_PULSE) return -EINVAL; break; default: @@ -1482,7 +1482,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id) kref_init(&tx->ref); ir->tx = tx; - ir->l->features |= LIRC_CAN_SEND_LIRCCODE; + ir->l->features |= LIRC_CAN_SEND_PULSE; mutex_init(&tx->client_lock); tx->c = client; tx->need_boot = 1; -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH stable v4.14 2/2] media: staging: lirc_zilog: incorrect reference counting

by Sean Young

Whenever poll is called, the reference count is increased but never decreased. This means that on rmmod, the lirc_thread is not stopped, and will trample over freed memory. Zilog/Hauppauge IR driver unloaded BUG: unable to handle kernel paging request at ffffffffc17ba640 Oops: 0010 [#1] SMP CPU: 1 PID: 667 Comm: zilog-rx-i2c-1 Tainted: P C OE 4.13.16-302.fc27.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F6 08/06/2009 task: ffff964eb452ca00 task.stack: ffffb254414dc000 RIP: 0010:0xffffffffc17ba640 RSP: 0018:ffffb254414dfe78 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff964ec1b35890 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffffb254414dff00 R08: 000000000000036e R09: ffff964ecfc8dfd0 R10: ffffb254414dfe78 R11: 00000000000f4240 R12: ffff964ec2bf28a0 R13: ffff964ec1b358a8 R14: ffff964ec1b358d0 R15: ffff964ec1b35800 FS: 0000000000000000(0000) GS:ffff964ecfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc17ba640 CR3: 000000023058c000 CR4: 00000000000006e0 Call Trace: kthread+0x125/0x140 ? kthread_park+0x60/0x60 ? do_syscall_64+0x67/0x140 ret_from_fork+0x25/0x30 Code: Bad RIP value. RIP: 0xffffffffc17ba640 RSP: ffffb254414dfe78 CR2: ffffffffc17ba640 Note that zilog-rx-i2c-1 should have exited by now, but hasn't due to the missing put in poll(). This code has been replaced completely in kernel v4.16 by a new driver, see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and commit f95367a7b758 ("media: staging: remove lirc_zilog driver"). Cc: stable(a)vger.kernel.org # v4.15- (all up to and including v4.15) Reported-by: Warren Sturm <warren.sturm(a)gmail.com> Tested-by: Warren Sturm <warren.sturm(a)gmail.com> Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/staging/media/lirc/lirc_zilog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c index 26dd32d5b5b2..e35e1b2160e3 100644 --- a/drivers/staging/media/lirc/lirc_zilog.c +++ b/drivers/staging/media/lirc/lirc_zilog.c @@ -1228,6 +1228,7 @@ static unsigned int poll(struct file *filep, poll_table *wait) dev_dbg(ir->l.dev, "%s result = %s\n", __func__, ret ? "POLLIN|POLLRDNORM" : "none"); + put_ir_rx(rx, false); return ret; } -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH stable v4.14 1/2] Revert "media: lirc_zilog: driver only sends LIRCCODE"

by Sean Young

The lirc config documented here https://www.blushingpenguin.com/mark/blog/?p=24 uses raw_codes for sending IR. Each key only has one pulse, which in fact is an index into the haup-ir-blaster.bin file. Changing the driver to LIRCCODE (although more accurate) breaks this configuration. This code has been replaced completely in kernel v4.16 by a new driver, see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and commit f95367a7b758 ("media: staging: remove lirc_zilog driver"). This reverts commit 89d8a2cc51d1f29ea24a0b44dde13253141190a0. Fixes: 615cd3fe6ccc ("[media] media: lirc_dev: make better use of file->private_data") Cc: stable(a)vger.kernel.org # v4.14-v4.15 Reported-by: Warren Sturm <warren.sturm(a)gmail.com> Tested-by: Warren Sturm <warren.sturm(a)gmail.com> Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/staging/media/lirc/lirc_zilog.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c index 71af13bd0ebd..26dd32d5b5b2 100644 --- a/drivers/staging/media/lirc/lirc_zilog.c +++ b/drivers/staging/media/lirc/lirc_zilog.c @@ -288,7 +288,7 @@ static void release_ir_tx(struct kref *ref) struct IR_tx *tx = container_of(ref, struct IR_tx, ref); struct IR *ir = tx->ir; - ir->l.features &= ~LIRC_CAN_SEND_LIRCCODE; + ir->l.features &= ~LIRC_CAN_SEND_PULSE; /* Don't put_ir_device(tx->ir) here, so our lock doesn't get freed */ ir->tx = NULL; kfree(tx); @@ -1267,14 +1267,14 @@ static long ioctl(struct file *filep, unsigned int cmd, unsigned long arg) if (!(features & LIRC_CAN_SEND_MASK)) return -ENOTTY; - result = put_user(LIRC_MODE_LIRCCODE, uptr); + result = put_user(LIRC_MODE_PULSE, uptr); break; case LIRC_SET_SEND_MODE: if (!(features & LIRC_CAN_SEND_MASK)) return -ENOTTY; result = get_user(mode, uptr); - if (!result && mode != LIRC_MODE_LIRCCODE) + if (!result && mode != LIRC_MODE_PULSE) return -EINVAL; break; default: @@ -1512,7 +1512,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id) kref_init(&tx->ref); ir->tx = tx; - ir->l.features |= LIRC_CAN_SEND_LIRCCODE; + ir->l.features |= LIRC_CAN_SEND_PULSE; mutex_init(&tx->client_lock); tx->c = client; tx->need_boot = 1; -- 2.14.3

7 years, 8 months

1
0
0 0

Inbox SMTP, Inbox Webmail, I Sell Sure Spamming Toolz

by Mr Spamming

I Sell Sure Spamming Toolz What we have on Stock Daily Inbox Webmail Inbox SMTP Fresh USA email leads Fresh Canada email leads Fresh Loan email leads Fresh Business emails leads Real Eastate email leads Conference delegates email leads Fresh Job Seaker emails cPanel HTTP and HTTPs Shell Zip/Unzipp Mailer RDP All ScamPages Bank ScamPage Add me on whatsapp or call me Watsapp: +2348107268246 Only Real buyers

7 years, 8 months

1
0
0 0

Request for Quotation

by Mohammed

Hello, Good day, I am Mohammed, Our company is interested in your product. We have gone through your product site online and wish to make order of your product. Please do send us details of your products and company to our {email} Also provide with the recent price We await your response with quotation and specification. [1] Payment terms [2] And your products Warranty (3] Minimum Order Quantity Mohammed /Purchasing Manager Telephone: +966 3 867 1902 Fax: +966 3 867 3435 tr.export.import(a)outlook.com PAN TRADING EQUIPMENT'S WORLDWIDE Address: Dallah street, Al Rehab Saudi Arabia

7 years, 8 months

1
0
0 0

Important regression fix patch

by Mauro Carvalho Chehab

Hi Greg, There are two important v4l2-core fixes on the patches merged this week by Linux. 1) media: v4l2-core: fix size of devnode_nums[] bitarray This patch correct a regression against Kernel 4.16. It affects notebooks with advanced Synaptics mice (and similar touch devices). On those devices, the pad produces an image with is handled via V4L2. Without this patch, the input driver OOPSes at probing time: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… 2) v4l2-compat-ioctl32: don't oops on overlay This patch complements the security fix we've made at the V4L2 core compat32 logic. It fixes an illegal use of an __user pointer without first convert into a Kernel pointer with get_user(). It wasn't detect before, as it uses an obscure streaming mode of V4L2 (overlay mode): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… This one should go all the way down to stable Kernels. Here, I was able to reproduce the bug with both upstream Kernel and Kernel 3.18. The patch applied without any conflicts on both. Could you please add both on your next set of -stable releases? Thanks, Mauro

7 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror