<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 19:30:15 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03160</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03160</link>
      <description>bdu:2025-03160</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03160</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-53142</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-53142</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-53142</guid>
    </item>
    <item>
      <title>certfr-2024-avi-1102 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1102</link>
      <description>certfr-2024-avi-1102</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-1102</guid>
    </item>
    <item>
      <title>EUVD-2026-313627</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313627</link>
      <description>EUVD-2026-313627</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313627</guid>
    </item>
    <item>
      <title>fkie_cve-2024-53142</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-53142</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;initramfs: avoid filename buffer overrun&lt;/p&gt;
&lt;p&gt;The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:&lt;/p&gt;
&lt;p&gt;37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0&lt;/p&gt;
&lt;p&gt;When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().&lt;/p&gt;
&lt;p&gt;If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn&amp;#39;t be considered a security
vulnerability.&lt;/p&gt;
&lt;p&gt;Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is
gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.&lt;/p&gt;
&lt;p&gt;---- repr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;initramfs: avoid filename buffer overrun&lt;/p&gt;
&lt;p&gt;The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:&lt;/p&gt;
&lt;p&gt;37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0&lt;/p&gt;
&lt;p&gt;When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().&lt;/p&gt;
&lt;p&gt;If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn&amp;#39;t be considered a security
vulnerability.&lt;/p&gt;
&lt;p&gt;Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is
gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.&lt;/p&gt;
&lt;p&gt;---- repr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-53142</guid>
    </item>
    <item>
      <title>GHSA-73xg-5c69-2755</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-73xg-5c69-2755</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;initramfs: avoid filename buffer overrun&lt;/p&gt;
&lt;p&gt;The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:&lt;/p&gt;
&lt;p&gt;37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0&lt;/p&gt;
&lt;p&gt;When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().&lt;/p&gt;
&lt;p&gt;If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn&amp;#39;t be considered a security
vulnerability.&lt;/p&gt;
&lt;p&gt;Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is
gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.&lt;/p&gt;
&lt;p&gt;---- repr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;initramfs: avoid filename buffer overrun&lt;/p&gt;
&lt;p&gt;The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:&lt;/p&gt;
&lt;p&gt;37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0&lt;/p&gt;
&lt;p&gt;When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().&lt;/p&gt;
&lt;p&gt;If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn&amp;#39;t be considered a security
vulnerability.&lt;/p&gt;
&lt;p&gt;Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is
gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.&lt;/p&gt;
&lt;p&gt;---- repr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-73xg-5c69-2755</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-53142 — initramfs: avoid filename buffer overrun</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-53142</link>
      <description>msrc_CVE-2024-53142</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-53142</guid>
    </item>
    <item>
      <title>OESA-2024-2569 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2569</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
dmaengine: idxd: Let probe fail when workqueue cannot be enabled&#13;
&#13;
The workqueue is enabled when the appropriate driver is loaded and
disabled when the driver is removed. When the driver is removed it
assumes that the workqueue was enabled successfully and proceeds to
free allocations made during workqueue enabling.&#13;
&#13;
Failure during workqueue enabling does not prevent the driver from
being loaded. This is because the error path within drv_enable_wq()
returns success unless a second failure is encountered
during the error path. By returning success it is possible to load
the driver even if the workqueue cannot be enabled and
allocations that do not exist are attempted to be freed during
driver remove.&#13;
&#13;
Some examples of problematic flows:
(a)&#13;
&#13;
 idxd_dmaengine_drv_probe() -&amp;amp;gt; drv_enable_wq() -&amp;amp;gt; idxd_wq_request_irq():
 In above flow, if idxd_wq_request_irq() fails then
 idxd_wq_unmap_portal() is called on error exit path, but
 drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The
 driver is thus loaded successfully.&#13;
&#13;
 idxd_dmaengine_drv_remove()-&amp;amp;gt;drv_disable_wq()-&amp;amp;gt;idxd_wq_unmap_portal()
 Above flow on driver unload triggers the WARN in devm_iounmap() because
 the device resource has already been removed during error path of
 drv_enable_wq().&#13;
&#13;
(b)&#13;
&#13;
 idxd_dmaengine_drv_probe() -&amp;amp;gt; drv_enable_wq() -&amp;amp;g…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
dmaengine: idxd: Let probe fail when workqueue cannot be enabled&#13;
&#13;
The workqueue is enabled when the appropriate driver is loaded and
disabled when the driver is removed. When the driver is removed it
assumes that the workqueue was enabled successfully and proceeds to
free allocations made during workqueue enabling.&#13;
&#13;
Failure during workqueue enabling does not prevent the driver from
being loaded. This is because the error path within drv_enable_wq()
returns success unless a second failure is encountered
during the error path. By returning success it is possible to load
the driver even if the workqueue cannot be enabled and
allocations that do not exist are attempted to be freed during
driver remove.&#13;
&#13;
Some examples of problematic flows:
(a)&#13;
&#13;
 idxd_dmaengine_drv_probe() -&amp;amp;gt; drv_enable_wq() -&amp;amp;gt; idxd_wq_request_irq():
 In above flow, if idxd_wq_request_irq() fails then
 idxd_wq_unmap_portal() is called on error exit path, but
 drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The
 driver is thus loaded successfully.&#13;
&#13;
 idxd_dmaengine_drv_remove()-&amp;amp;gt;drv_disable_wq()-&amp;amp;gt;idxd_wq_unmap_portal()
 Above flow on driver unload triggers the WARN in devm_iounmap() because
 the device resource has already been removed during error path of
 drv_enable_wq().&#13;
&#13;
(b)&#13;
&#13;
 idxd_dmaengine_drv_probe() -&amp;amp;gt; drv_enable_wq() -&amp;amp;g…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2569</guid>
    </item>
    <item>
      <title>RHSA-2025:6966 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:6966</link>
      <description>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:6966</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:4367-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:4367-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:4367-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-53142</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53142</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 195 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as:  37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data ...  55 ============= ================== =========================  56 Field name    Field size         Meaning  57 ============= ================== ========================= ...  70 c_namesize    8 bytes            Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn&amp;#39;t be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g.   ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.s…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 195 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as:  37 cpio_file := ALGN(4) + cpio_header + filename + &amp;#34;\0&amp;#34; + ALGN(4) + data ...  55 ============= ================== =========================  56 Field name    Field size         Meaning  57 ============= ================== ========================= ...  70 c_namesize    8 bytes            Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel&amp;#39;s do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn&amp;#39;t be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g.   ./reproducer.sh | gzip &amp;gt;&amp;gt; /myinitramfs It&amp;#39;s easiest to observe non-zero uninitialized memory when the output is gzipped, as it&amp;#39;ll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53142</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3619 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3619</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um seine Privilegien zu erhöhen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um seine Privilegien zu erhöhen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3619</guid>
    </item>
  </channel>
</rss>
