Linux: >> Linux Kernel >> 4.14.307 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't ignore the return code of svc_proc_register()
Currently, nfsd_proc_stat_init() ignores the return value of
svc_proc_register(). If the procfile creation fails, then the kernel
will WARN when it tries to remove the entry later.
Fix nfsd_proc_stat_init() to return the same type of pointer as
svc_proc_register(), and fix up nfsd_net_init() to check that and fail
the nfsd_net construction if it occurs.
svc_proc_register() can fail if the dentry can't be allocated, or if an
identical dentry already exists. The second case is pretty unlikely in
the nfsd_net construction codepath, so if this happens, return -ENOMEM.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
media: streamzap: fix race between device disconnection and urb callback
Syzkaller has reported a general protection fault at function
ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer
dereference of dev->raw pointer, even though it is checked for NULL in
the same function, which means there is a race condition. It occurs due
to the incorrect order of actions in the streamzap_disconnect() function:
rc_unregister_device() is called before usb_kill_urb(). The dev->raw
pointer is freed and set to NULL in rc_unregister_device(), and only
after that usb_kill_urb() waits for in-progress requests to finish.
If rc_unregister_device() is called while streamzap_callback() handler is
not finished, this can lead to accessing freed resources. Thus
rc_unregister_device() should be called after usb_kill_urb().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score
4.7
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
media: vimc: skip .s_stream() for stopped entities
Syzbot reported [1] a warning prompted by a check in call_s_stream()
that checks whether .s_stream() operation is warranted for unstarted
or stopped subdevs.
Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that
entities skip a call to .s_stream() unless they have been previously
properly started.
[1] Syzbot report:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460
Modules linked in:
CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0
...
Call Trace:
<TASK>
vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62
vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]
vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203
vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256
vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789
vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348
vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]
vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118
__video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122
video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463
v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl fs/ioctl.c:892 [inline]
__x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2b85c01b19
...
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before truncation in jfs_truncate_nolock()
Added a check for "read-only" mode in the `jfs_truncate_nolock`
function to avoid errors related to writing to a read-only
filesystem.
Call stack:
block_write_begin() {
jfs_write_failed() {
jfs_truncate() {
jfs_truncate_nolock() {
txEnd() {
...
log = JFS_SBI(tblk->sb)->log;
// (log == NULL)
If the `isReadOnly(ip)` condition is triggered in
`jfs_truncate_nolock`, the function execution will stop, and no
further data modification will occur. Instead, the `xtTruncate`
function will be called with the "COMMIT_WMAP" flag, preventing
modifications in "read-only" mode.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before txBeginAnon() call
Added a read-only check before calling `txBeginAnon` in `extAlloc`
and `extRecord`. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.
Call trace:
txBeginAnon+0xac/0x154
extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78
jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248
__block_write_begin_int+0x580/0x166c fs/buffer.c:2128
__block_write_begin fs/buffer.c:2177 [inline]
block_write_begin+0x98/0x11c fs/buffer.c:2236
jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to
restore the original 5-tuple in case of SNAT, to be able to find the
right socket (if any). Then socket_match() can correctly check whether
the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this
conntrack lookup, making xt_socket fail to match on the socket when the
packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on `-m socket --transparent` and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop
bug, one without) were seen to cause IOMMU faults after some Missed
Service Errors. Faulting address is immediately after a transfer ring
segment and patched dynamic debug messages revealed that the MSE was
received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to
the HC. Below, it reports MSE in segment at ff1e8000, plows through a
zero-filled page at ff1e9000 and starts reporting events for TRBs in
page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to
Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to
random buffers of pending TDs on other endpoints (either IN or OUT),
other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it
caused by the above? I don't know, but it may have been. The disk
was working without any other issues and generated PCIe traffic to
starve the NEC of upstream BW and trigger those MSEs. The two HCs
shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting
the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
known which also expect the bit to be set and they ignore Link TRBs if
it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
tens of MSEs per second and runs into the bug within seconds. Chaining
Link TRBs allows the same workload to run for many minutes, many times.
No ne
---truncated---
CVSS Score
7.8
EPSS Score
0.001
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfx___alloc_skb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfx___sys_sendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] __x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-04-16
In the Linux kernel, the following vulnerability has been resolved:
regulator: check that dummy regulator has been probed before using it
Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-08
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on
error. Returning NULL will lead to a NULL dereference.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-04-03